Avoid user-confusion by not offering undesired audio sources #7
Comments
|
My understanding of today's WebRTC Working Group meeting was that the suggestion in this slide was generally accepted, with some bikeshedding left over names. I propose that we reuse displaycapturesurfacetype but name the key |
|
Proposal from editor's meeting: add something like 'boolean avoidSystemAudio' member field in https://w3c.github.io/mediacapture-screen-share/#dom-displaymediastreamconstraints. |
|
The brainstorming session continued and we landed on: enum SystemAudioPreferenceEnum {
"include",
"exclude"
};
dictionary DisplayMediaStreamConstraints {
SystemAudioPreferenceEnum systemAudio;
}; |
|
Expectedly, some Web applications (Meet) are now asking for the ability to exclude both window- and system-audio, and only prompt the user for tab-audio (alongside video, of course). I think it's always good for browsers to get out of the applications' way when they wish to ask for less permissions, so I propose we follow suit on systemAudio Namely: enum WindowAudioPreferenceEnum {
"include",
"exclude"
};
dictionary DisplayMediaStreamConstraints {
WindowAudioPreferenceEnum windowAudio;
};And text saying that Wdys? -- |
User agents may offer audio to be captured alongside video, if the application specifies
{audio: true}, or mapsaudioto anything else that's different fromfalse. But not all audio is created alike. Consider video-conferencing applications. Tab-audio is often useful, and can be shared with remote participants. But system-audio includes participants' own audio, and it is NOT desirable to share it back.State of the art? VC applications can ask for "audio", use it if it's tab-audio, and discard it otherwise. This works, but it's sub-optimal. The user is left confused. The user wanted to share system-audio, the user was offered to share-system, the user explicitly approved sharing system-audio - and now remote participants are telling the user that they can't, in fact, hear the system-audio. Now how messed up is that?!
It'd be better if we allowed the application to ask for less. Allow the application to ask for audio only in conjunction with surfaces of type X. (For example, with constraints.)
I think we should debate this in order:
The text was updated successfully, but these errors were encountered: