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

Behavior when audio device is changed by user-agent #100

Open NoahRoseLedesma opened 4 years ago

NoahRoseLedesma commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 https://github.com/w3c/mediacapture-main/issues/693.

Per https://github.com/w3c/mediacapture-output/issues/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 commented 4 years ago

@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 commented 4 years ago

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

NoahRoseLedesma commented 4 years ago

@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 commented 3 years ago

@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.