youennf
commented
4 years ago Here are a few scenarios/ideas to start the discussion.
The first scenario is that the speaker to be used is the one related to the microphone disclosed by getUserMedia. In that case, the specs seem fine as is: on every visit, the web page will start with getUserMedia and will then select the speaker exposed after getUserMedia.
The second scenario is the more general case where microphone is not in use.
If the device info(s) being used were statically exposed (https://github.com/w3c/mediacapture-output/issues/93), they will most probably be exposed again so setSinkId can be used directly.
If device info(s) were exposed to the web page by selectAudioOutput and used to set the whole page audio output (https://github.com/w3c/mediacapture-output/issues/87), the user agent may decide to set it back on next visit, based on some heuristics. This is easier done on a page scope than an individual media element scope.
In the more complex case where selectAudioOutput is used on individual elements or called several times to use multiple speakers, a possibility is for selectAudioOutput to take an additional ‘deviceId’ parameter. If the ‘deviceId’ matches an existing device, the user agent may decide to not prompt the user (let’s say user granted persistent access) and resolve the promise with the corresponding MediaDeviceInfo. This deviceId can then be used by setSinkID. If the ‘deviceId’ does not match any available speaker, it should be ignored and selectAudioOutput would continue with a prompt. This hopefully should prevent pages to passively monitor speakers. The potential downside here is that selectAudioOutput might prompt in some cases but not others.
A web site might allow a user to select speakers on first visit. On a second visit, it would be convenient for the user to be able to easily select the exact same speaker configuration. We could envision the user agent to do this or let the web page handle it.