Behavior when audio device is changed by user-agent

[NoahRoseLedesma]

Chrome is introducing a feature that would allow users to reroute the audio output of a page to other devices from a UI in the toolbar. Presumably when audio is rerouted to a non-default device the HTMLMediaElement sinkId attribute should be updated. However the current specification does not provide a means of informing applications of this change. I would like to discuss how we might accommodate this functionality within this specification.

Perhaps an EventHandler attribute should be added to HTMLMediaElement to fire when a sink id change has occurred from a user-agent source?

[alvestrand]

Would the point of such a toolbar mechanism be to redirect all audio for the tab, all the audio that isn't sent to an explicit source, or some other effect? (realizing that sending audio from different media elements in a single tab to different destinations seems to be intended to be supported by spec, it's not likely to be common, but might happen).

[NoahRoseLedesma]

The toolbar mechanism would redirect all audio for the tab. If audio from different media elements in a single tab is being sent to different destinations, this toolbar mechanism would redirect all audio to one destination.

[guest271314]

Chrome is introducing a feature that would allow users to reroute the audio output of a page to other devices from a UI in the toolbar.

Can you kindly link to the documentation?

At Linux would suggest using pavucontrol, as enumerateDevices() is not dynamic.

[NoahRoseLedesma]

Can you kindly link to the documentation?

There currently is not any public documentation on this feature.

At Linux would suggest using pavucontrol, as enumerateDevices() is not dynamic.

I am having difficulty understanding how this comment relates to the issue. Could you expand upon this?

[guest271314]

Due to Chromium not supporting capture of monitor devices it is necessary to utilize workarounds to capture devices other than a microphone input device. When that occurs, since Chromium source code specifically fails to start audio when monitor device is set as default or list the devices at all, monitor devices are not listed by enumerateDevices() when pavucontrol dynamically changes the input being captured, see w3c/mediacapture-main#693.

Per #101 the expected result of this specification re selectAudioOutput is not to capture audio output, as in output to headphones and speakers, which is what lead to filing the linked issue.

From perspective here all audio devices, input, output, virtual devices, should be capable of being selected and captured. That is not specified. Thus, ask for that capability to be specified, and in the interim create workaround and proof-of-concepts that could potentially work as intended to capture and device and access that capture in the given execution context.

[guest271314]

@NoahRoseLedesma Asked for link to primary source documentation for the claim

Chrome is introducing a feature that would allow users to reroute the audio output of a page to other devices from a UI in the toolbar.

which would necessarily not include monitor devices per https://bugs.chromium.org/p/chromium/issues/detail?id=1114422#c9, or other projects at Chromium, Chrome are operating outside of the scope definitively stated.

[guidou]

@NoahRoseLedesma what's the use case for the event?

[NoahRoseLedesma]

@guidou To notify web applications when audio is being played from a different device. For example, this would be needed to keep applications that display the current device in sync after a device change occurred via the new Chrome UI.

[guidou]

@NoahRoseLedesma sorry for the late reply. I would interpret this feature as a change of the default device but localized to a particular tab. In this case, it would make sense to change the sinkId field only for elements that have an explicit device ID previously set with setSinkId.