search

w3c / mediacapture-output

API to manage the rendering of audio on any audio output device
https://w3c.github.io/mediacapture-output/
Other
26 stars 25 forks source link

Is reverting to different speakers from a background tab a valid use case? #129

Open jan-ivar opened 2 years ago

jan-ivar commented 2 years ago

The spec says "When the audio device ... is no longer available, the user agent must take no action".

@alvestrand wrote in https://github.com/w3c/mediacapture-main/issues/842#issuecomment-1006653409:

The interesting version of devicechange with backgrounded tabs is if someone unplugs his headset while the tab is backgrounded, and expects sound to automagically switch to speakers without having to foreground the tab first.

JS can't intervene if backgrounded, since enumeration may not work (enumerateDevices "MAY ... wait ... until ... focus"), so there's no general solution for this. Even worse, there's a solution in some user agents but not others.

But is this behavior desirable? The VC use case from a private office makes sense. OTOH, someone passively attending from a library worrying audio might start blaring out of their laptop speakers should their headset accidentally disconnect, seems undesirable.

alvestrand commented 2 years ago

I think Jan-Ivar's comment points out that the platform will be unable to confidently switch output devices on its own, so it seems that if we switch at all, we need to punt the choice of how to switch to JS.

One solution would be to define that a change in an output device that is in active use acts like a substitute for focus in the permission-gating algorithm, so that the signal gets fired and the enumerateDevices works within the callback from that signal.

This could get messy fast.