Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conditional Suppression of Local Audio Playback from Captured Tab #161

Closed
eladalon1983 opened this issue Apr 2, 2021 · 8 comments · Fixed by #164
Closed

Conditional Suppression of Local Audio Playback from Captured Tab #161

eladalon1983 opened this issue Apr 2, 2021 · 8 comments · Fixed by #164
Assignees

Comments

@eladalon1983
Copy link
Member

eladalon1983 commented Apr 2, 2021

Consider a user with two open tabs - one with a VC app and one displaying some media. (E.g. Meet+YouTube, Teams+Twitter, or Zoom+Facebook.) Assume the VC tab is capturing the media-playing-tab using getDisplayMedia and sharing the resulting audio and video with remote participants. Sometimes it's desirable to suppress the captured tab's audio-playback over the local speakers, without preventing the audio from being captured. That is, the audio is is still captured, but is no longer routed to the local speakers. (Note, btw, that Chrome's hangouts-extension-based API does this very thing.) Rationale:

  1. The user could be driving audio from the captured tab to a separate set of speakers in the room in which they're sitting together with a few other people. Meet, for example, has a present-only mode, where the user joins a meeting for presenting only, and does not receive audio. In such a case, the user would not normally expect they have to mute their local machine's speakers via the OS.
  2. Meet has found that echo cancellation works better if the media-tab's captured audio is mirrored back to the user and is played back in the VC tab as though it were another participant's audio. Other VC apps likely find themselves in a similar situation.

I propose adding a way for an app to conditionally request that the captured tab's audio playback be suppressed while the capture is ongoing. We could introduce a new constraint called suppressLocalAudioPlayback and say that the user agent SHOULD/MAY respect this request. (In the case of multiple capturers - suppress local playback as long as at least one active capture exists with this particular constraint.)

@jan-ivar
Copy link
Member

jan-ivar commented Apr 3, 2021

I think the use case makes sense. Unlike for video, having multiple consumers of audio can prove challenging, and may inherently warrant either-or controls like this that flip between outputs that users hear, to avoid listening to overlapping audio.

I think a SHOULD is appropriate. Firefox shows a 🔈 in tab-headers of tabs that produce audio, that the user can click on to mute/unmute audio in that tab. I could see us integrating this feature with that — users would see the state change reflected there, and be able to interact with it to override it — to avoid multiple levels of muting.

@eladalon1983
Copy link
Member Author

Sorry for the churn. I'm used to Git, but not yet to Github. The right PR is now linked.

@murillo128
Copy link

My main use case requires to be able to both play the audio normally and capture it, but I am totally in favor of a way to enable or disable it via API, and the suppressLocalAudioPlayback constraint seems the good way to go.

One question, what would happen if there are several calls to getCurrentBrowsingContextMedia each one with different values? should the final value be and and or and or of all of them? (I don't really have preferences here as it seems an edge case)

@eladalon1983
Copy link
Member Author

Playback suppressed if-and-only-if >= 1 active captures with suppressLocalAudioPlayback specified.

@murillo128
Copy link

that would work for me

@eladalon1983
Copy link
Member Author

@jan-ivar, this did not fit into this month's interim. Do we need to wait for next month's, thereby also reducing the amount of time available for other issues, or can we settle this over Github? IMHO this issue has not seen much activity because it does not face opposition.

@jan-ivar
Copy link
Member

@eladalon1983 That is unfortunate, and has happened to me as well. Unfortunately, not all members follow issues and PRs closely. I think we should do all we can to finish review to get this PR in ship shape, and put it first on the agenda at next meeting. If you're able to solicit feedback early from folks that is always helpful of course, to minimize chances of unforeseen issues at the meeting.

@eladalon1983
Copy link
Member Author

eladalon1983 commented Jun 7, 2021

Status update for transparency's sake - we have consensus and the PR (#164) is under review, with most remaining issues appearing to be technicalities.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants