Why prompt for a subset of stored speakers or speakers setSinkId already accepts?

[jan-ivar]

In #116 (comment) @youennf explains the model well:

The model is as follow:
a. If enumerateDevices is exposing audiooutput devices, deviceId can be used by setSinkId.

...so why should selectAudioOutput({deviceId}) prompt? "If deviceId is not "" and matches an id previously exposed by selectAudioOutput in an earlier browsing session, the user agent MAY [skip the prompt]"

This forces apps who already have transient activation to vet their stored ids through enumerateDevices to conditionally skip selectAudioOutput to avoid a needless prompt.

b. If the application knows of a deviceId used in the past but enumerateDevices is not exposing it, the application is expected to call selectAudioOutput with the corresponding deviceId.
...
Case b. can happen for deviceId previously revealed by selectAudioOutput or getUserMedia.

Except case b will prompt for deviceIds revealed by getUserMedia. This seems surprising.

This seems like it could be streamlined. User agents should be allowed to bypass the prompt for deviceIds that are good to go, and whether they came from selectAudioOutput or getUserMedia.

[youennf]

I agree the intent is to allow the flexibility for skipping prompts for devices that have been exposed in the past, and this sentence is forgetting about getUserMedia here.

@jan-ivar, is there anything more to this issue?

[dontcallmedom-bot]

This issue was discussed in WebRTC August 27 2024 meeting – 27 August 2024 (Issue #142 / PR #143 Why prompt for a subset of stored speakers or speakers setSinkId already accepts?)