API to request audio output device selection

[youennf]

PR for #83

[jan-ivar]

I like this direction! Mostly nits and questions.

My main question is how to map temporary permissions?

Firefox has avoided session-based permissions thus far, doing one-offs or persistent permission only. But this API inherently needs a different kind of temporary permission I think, one that probably expires at the end of the page? Is that what Safari does?

[jan-ivar]

Step numbers may change. I think in mediacapture-main we should break out steps 2.5.3-2.5.5 into a new create a MediaDeviceInfo algorithm, and call that here. That way, all the storage stuff around deviceId and groupId can live there.

[youennf]

Agreed, I did this draft as a first step before modifying other specs. There is also the need to add a bunch of references for promises/permission

[jan-ivar]

In my mind, Firefox would add ☑ Remember this decision to this prompt (on by default).

When the box is ☐ unchecked, return a deviceId which is good immediately only (timeout? eos?)
When the box is ☑ checked, return a persistent deviceId.

But is non-persistent permission important for speakers? There's no snooping risk.

Having the option to persist these things seems necessary to enable future multi-speaker use cases.

It also seems odd if a site can remember I use my bluetooth headset as a mic, but not as a speaker.

Which brings me to...

Does this API needs to accept constraints? Specifically, the deviceId or groupId constraint, to locate different features of a user's preferred physical device? This could then either limit choices in the prompt (exact) or at least influence the default choice (ideal) (like Firefox's cam/mic prompts today).

Otherwise, a site cannot remember the user's choice from last time without permission.
Said differently: revoking or not granting persistent permission would forget the user's preference.

So far, we've been able to distinguish memory from permission.

[youennf]

I think we should discuss the persistency in a follow-up discussion.
We may be able to provide some persistency similarly to what I described at the last interim for setSinkId:

• We add an optional sinkId parameter to the requestAudioOutputDevice method.
• If it is present and the ID does not refer to anything, prompt the user
• Otherwise, we could prompt the user with preselected entry or we could resolve without even prompting the user (this device then shows up in enumerateDevices and can be used by setSinkId)

[jan-ivar]

At end of call, I think we decided editors can integrate once follow-up issue has been filed for adding hooks.

[youennf]

Filed w3c/mediacapture-main#703

[bradisbell]

This change seems to propose disallowing a web application from getting an output device list and presenting it to the user, in favor of a browser-specific UI for doing this. Is this correct?

Such a change would break a lot of use cases. The browser doesn't know the context of what the application is trying to do. For example, it's common in my applications to use multiple audio outputs simultaneously. As part of saved config, I know what devices should be used for what, and when, because the user previously configured them in my application. If instead on every page load I have to request the user multiple times to select a device, this would be very damaging to the user experience.

[youennf]

This change seems to propose disallowing a web application from getting an output device list and presenting it to the user, in favor of a browser-specific UI for doing this. Is this correct?

This is correct.

As part of saved config, I know what devices should be used for what, and when, because the user previously configured them in my application.

This is a scenario that makes sense and we plan to work on that, with the same constraint as getUserMedia: we should not allow passive monitoring of output devices by a web page.

[youennf]

@bradisbell I filed #99