Selecting audio output in case device info permission is not granted

[youennf]

Currently, selecting audio output is difficult to implement if camera/microphone access is not granted. This is a limitation that we should try to overcome.
This might be solvable by investigate ways to discover output device IDs outside of enumerateDevices.

[achronop]

Currently obtaining deviceID is possible outside gUM, with enumerateDevices. However, the devices are not specified since the label attribute is missing, given that enumerateDevices provides deviceID but without gUM the device label is empty.

In my understanding, by reading #2 and #71, there is still a question of how to obtain the label to provide the user with a meaningful list of device names, without the gUM. Therefore, do you mean how the output device labels should be obtained outside gUM/enumerateDevices?

[achronop]

Currently obtaining deviceID is possible outside gUM, with enumerateDevices.

Hmm I see that Safari does not set the deviceID either.

Nevertheless, this issue seems to be benefited by what is being discussed in mediacapture-main#612. Introducing a permission prompt in enumerateDevices would allow the user to authorize the access to the label and deviceID. Additionally, that authorization could be further used to enable the setSinkId; which means that the device-info permission of an output device will be granted by the enumerateDevices prompt and setSinkId will be based on that permission. This will remove the need for gUM on playback only scenarios.

[guidou]

The need for gUM in playback-only scenarios in Chrome is a bug due to the lack of a speaker permission (which exists in the permission spec, but is not implemented in Chrome). See crbug.com/865799.
setSinkId could ask for a specific audio output permission (for nondefault devices).

[youennf]

Adding a prompt might be be difficult to implement, in particular the message to convey to users.
If we keep the idea of relying on IDs and setSinkId, there are a few possibilities that are worth to explore:

• Some devices are already known to the web page. Exposing these devices is then probably fine. A phone usually has an ear-piece speaker and a loud speaker. They could be exposed as is and/or represented as specific deviceId values.
• Some applications do not want to pick a specific device but a specific behaviour. For instance, some applications are phone-like applications and want to pick the most suitable speaker available for that purpose, be it the earpiece speaker, a BT headset... This could be expressed in different ways. One possibility would be to define specific deviceId values.
• Some applications want to allow the user to select a specific device in their UI. We could define an API that triggers a device picker, similarly to screen capture that allows a user to select a specific screen/window. This is also done this way in Safari to select AirPlay devices. The user selects a specific device and the corresponding deviceId is exposed to the web page.

[achronop]

Regarding the already known devices and the specific behavior devices, having specific values as device IDs could be a useful approach. However, a form of authorization is still required in case that the selected device is not the system default one. Otherwise, access is still allowed to devices without user permission.

On a minor note, implementing behavior-specific device IDs could be tricky among the different platforms.

Defining an API which triggers a device picker also makes sense and would be a good idea. An additional thought would be to embody this functionality to the setSinkId directly.

[kmduk]

Something related to this is which volume setting on a phone is applied to the audio element output.
For example, I have seen that with Chrome on Android an audio element volume is normally controlled by the 'media' volume setting. However, once gUM has been called (and accepted) the 'call' volume setting is used.
Could specific predefined deviceId values effectively determine the purpose of the audio being played?

[alvestrand]

I can't quite figure out what the stuff is trying to accomplish here, or how.
The most common case for switching output device is to put audio on an USB / Bluetooth headset.
Is it the intention that "play on headset" needs a permission prompt every time?
Is that reasonable for the user?

[aboba]

There are applications which do not need access to the camera/microphone but which do need to select the output device. An example is an online course or a company meeting application. If the participant is not asking a question there is no need for access to the camera/microphone (and requesting that access could appear creepy). Yet, there may be a need to select the output device (e.g. play via a headset rather than speakers so as not to interfere with other students/employees).

[guidou]

It should be made clear that prompting should not be required when switching to the system default device, which is always authorized.

[youennf]

Agreed with @aboba.
setSinkId is bigger than WebRTC also.
And some WebRTC websites allow users to deny camera/microphone, but still enter the room and potentially later grant mic if needed. In all cases, it would be nice for user to select the audio output.

Another case is that you initially deny camera access, and later grants

Is it the intention that "play on headset" needs a permission prompt every time?
Is that reasonable for the user?

The headset might actually be the default output, or the default output used by the browser.
We should only need that API when the default is not good for the user.
We can also discuss the persistency of the information provided by this API.

[youennf]

Another option:

• Update setSinkId to not reject but prompt if deviceId is not in the enumerateDevices list.

[dontcallmedom]

I believe #86 closed this