- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Fri, 12 Oct 2018 09:57:36 +0000
- To: public-webrtc-logs@w3.org
> And echo cancellation will go some way to address the problem. Perhaps, but I'm skeptical. Not only would screen sharing the application source reflect it back at 100% volume, each participant is a new possible source of echo with different delays and at different quality, it's not just your microphone. I am operating under the assumption that echo cancellation is not good enough (I don't have data to back this up) and we want to give browsers an _easy_ way out. > How important is this? Under this assumption, this feature is essential. We should not present false choices to the user that cause "echo bugs". > Given the acknowledged difficultly in isolating different audio sources we have, it seems like this is a difficult feature to implement. I don't expect UAs to implement excluding audio from any of the audio source configuration. Most likely they will exclude choices (e.g. instead of presenting all tabs as choices, presenting all tabs except the application tab as choices), but certain configurations might allow you to exclude a particular audio source (e.g. sharing a browser window and including audio sources from all tabs except the application tab) and then the browser should be _allowed_ to implement something usable without being _mandated_ to. There's always an easy way to satisfy this constraint: don't present problematic configurations as choices. If we don't have a constraint like this we might implicitly be forcing the browser to have a really good technical solution to the problem which we want to avoid or leaving it to the user to figure out whether or not a choice is valid for their applications' use case. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/79#issuecomment-429272689 using your GitHub account
Received on Friday, 12 October 2018 09:57:38 UTC