- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Thu, 04 Jan 2024 20:37:49 +0000
- To: public-webrtc-logs@w3.org
> The test page API is making design mistakes I think, it should not show AirPods if it does not know AirPods are available.
Absolutely. A superior test page would vet choices before presenting them by filtering out unavailable speakers. But the only way to do so would be through calling selectAudioOutput even earlier, underscoring the undesirability of a prompt.ยน
> 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?
Selection is a distraction. The flow is hitting PLAY, step 4 in the OP:
```js
go.onclick = async () => {
try {
if (localStorage.speakers) {
const deviceId = localStorage.speakers;
await audio.setSinkId((await selectAudioOutput({deviceId})).deviceId);
updateSelectors();
}
// code producing audio
```
In this case, no prompt is expected because the user just hit PLAY. The ability to reuse the same device as last time seems important.
---
<sub>1. No speakers show up in enumerateDevices(), because the test page doesn't use microphone. Even if it did, non-mic'ed speakers wouldn't show.</sub>
--
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-output/issues/137#issuecomment-1877729071 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 4 January 2024 20:37:51 UTC