Using default device ID for setSinkId()

[hoch]

Currently setSinkId() specification uses '' (empty string) for the default device, but other device related APIs have been using default as a proxy for the system default device.

There was a feature request from developers to add support for the default string for setSinkId() call.

Related issues in the browser bug tracker:
Chromium: https://crbug.com/40259875
FireFox: https://bugzilla.mozilla.org/show_bug.cgi?id=1879204#c0

[hoch]

@padenot Is the default device ID a common practice for FireFox as well?

[orottier]

What is the exact feature request?

1. To accept 'default' as an alias for ''. So context.sinkId = 'default'; context.sinkId == '' // true
2. To allow both '' and 'default' to specify the default sinkId. In that case library authors would have to check for both values to know if a default device was used
3. To change the default device specification from '' to 'default'. This is a backwards incompatible change

[padenot]

@padenot Is the default device ID a common practice for FireFox as well?

@jan-ivar, can you comment on what is customary in the various WebRTC APIs ?

@orottier, I'm leaning towards an alias in case there's any compat issue. Has that been implemented on your side already?

[orottier]

We have the sinkId feature implemented in both Rust and NodeJs and use '' as the default device specifier. However since we are still in a pre-v1.0 stage I would be fine with either decision. Our users need to track our changelog anyhow because we are still iterating on the API slightly.

[jan-ivar]

Is the default device ID a common practice for FireFox as well?

It is not. It's not in Safari either.

Only Chromium exposes discrete placeholder "Default - x" microphone and speaker (but not camera) choices to end-users:

5 devices.
audioinput: Default - MacBook Pro Microphone (Built-in) id=default group=...
audioinput: MacBook Pro Microphone (Built-in) id=b917fc01bb9a3a99d04317808... group=...
videoinput: FaceTime HD Camera (2C0E:82E3) id=beaed30c53b5507e19fe0ee6c5bd... group=...
audiooutput: Default - MacBook Pro Speakers (Built-in) id=default group=...
audiooutput: MacBook Pro Speakers (Built-in) id=bc32e126d87bee7105cab5ca5e... group=...

This is unnecessary since the spec says the first device of its kind is the system default device (see bug 1879204).

Compare to Firefox:

3 devices.
audioinput: MacBook Pro Microphone id=SRkigmqE1ivTclyNi6idZDQbsSxEN3ZrmZYk... group=...
videoinput: id= group=
audiooutput: MacBook Pro Speakers id=ujz2O0yf17h4myMqKEp+DPmm8vnxCuz7bskwg... group=...

...and Safari:

2 devices.
audioinput: MacBook Pro Microphone id=13813FC500D539C3D216628A086890B2959FBDC0 group=...
videoinput: FaceTime HD Camera id=D46A3793496A69FD135747B70C2E796416012F85 group=...

This is a web compat headache, because this placeholder speaker actively discourages webapps from handling the default "" speaker choice explicitly or presenting it as a choice in UX to users. This has led to reports of end-users unable to restore speakers in Firefox (because the website isn't giving them the choice).

And when done to spec, as in https://jan-ivar.github.io/dummy/gum_picker_output3.html it results in redundancy in Chrome:

Accepting "default" would seem to exacerbate this, further encouraging webapps to rely on chromium-only behavior.

[hoch]

Thanks for detailed response @jan-ivar!

The WG will review this again in the next teleconference.

[padenot]

AudioWG call 2024-05-14: the spec won't allow using "default" to mean the default device, "" (empty string) is the correct way to do this. No change to the spec is required, closing.