Re: [mediacapture-output] Undesirable prompt from selectAudioOutput({deviceId}) if valid device removed (#137)

The ability to resetup audio as the last visit would be nice to do, I am not sure selectAudioOutput is the full solution here.

The test page API is making design mistakes I think, it should not show AirPods if it does not know AirPods are available.
Maybe it is just me and I am too focused on the testing web page, but I do not see how rejecting here would make the user experience all that better. Which exact flow do we want to solve here by rejecting?

Getting back to the test page, AirPods are shown and selectAudioOutput is rejecting. The user expects audio to flow on AirPods.
But what will happen is that either audio will not flow at all or will flow on the default output (say headphones).

I'd like to see a more compelling flow where reject would be more useful.

With current selectAudioOutput, a typical flow would be AirPods UI being shown as greyed/inactive (or maybe `AirPods - not selected`) on reload and user would need to click on it to make it active via selectAudioOuput. There might be no prompt (`AirPods - selected` then) or there might be a prompt, in which case UI is updated depending on the result (`default` in case of reject, `headphones` if selected...).

-- 
GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/mediacapture-output/issues/137#issuecomment-1729878534 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 21 September 2023 16:05:23 UTC