- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Thu, 06 Dec 2018 11:35:02 +0000
- To: public-webrtc-logs@w3.org
If the echo cancellation is good enough, this constraint is not necessary, and it would probably be a bad idea to add it. Then we'd require implementations to be really good at it if they want to support audio. More information is needed. But _if_ it's not good enough then... The UA can't make a "best decision" without knowing what the application use case is. If the application doesn't specify, how would the UA know that origin audio is problematic? I think the UA would end up being overly defensive and exclude origin audio even when it would not be problematic. I.e. not being able to share desktop /w audio even in cases where the platform/browser supports it and the application could not be affected by echo. That's a shame for people who want to be able to do that. Alternatively, let the user choose and the user has nobody to blame but themselves if they make a bad choice. Perhaps this is valid. With regards to "not talking": I'm not a fan of "hey can everyone please be quiet, I'm about to hold a presentation". No more question and answers sections, that would involve someone talking. Or we are only interested in solving this use case for applications that implement a manual mute/unmuting buttons, meaning the presenter loses the ability to hear anyone not physically present while presenting. This sounds like a workaround rather than a solution. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/79#issuecomment-444842344 using your GitHub account
Received on Thursday, 6 December 2018 11:35:03 UTC