Design Review #766

#766: Output Device Selection in Web Audio API: AudioContext.setSinkId()

Opened Aug 30, 2022

Hello,

I'm requesting a TAG review of AudioContext.setSinkId().

AudioContext.setSinkId sets the ID of the audio device to use for output. This allows the AudioElement to route audio to a connected output device of user's choosing.

Explainer, User research, Security and Privacy self-review: Public Design Doc
Primary contacts (and their relationship to the specification):
- Hongchan Choi (@hoch), Google
- Paul Adenot (@padenot), Mozilla
Organization/project driving the design: W3C Audio WG
External status/issue trackers for this feature: https://chromestatus.com/feature/5190163462881280

Further details:

I have reviewed the TAG's Web Platform Design Principles
The group where the incubation/design work on this is being done (or is intended to be done in the future): Audio WG
The group where standardization of this work is intended to be done: Audio WG
Existing major pieces of multi-stakeholder review or discussion of this design:
- https://github.com/WebAudio/web-audio-api/issues/2400 (discussion)
- https://github.com/WebAudio/web-audio-api/pull/2498 (spec change PR)
Major unresolved issues with or opposition to this design: None

We'd prefer the TAG provide feedback as (please delete all but the desired option): ☂️ open a single issue in our GitHub repo for the entire review

Discussions

2022-10-10

Minutes

Max: Had a look at the explainer... very good question asked by Chris - why does web audio API need them... and why does HTML not have them... and should it? Also looked at the design of the API.. a lot of questions of other ways to work around this... one suggestion is to suggest the author to update the explainer to answer the 2nd question - why HTML doesn't solve the problem.. a selectaudiooutput api can do the same thing - but authors should update the explainer to explain why this API is not suitable for web audio...

Dan: that sounds great..

Max to leave comment accordingly

Sangwhan: is it an output device request?

Max: to enable the developer to select the output...

Sangwhan: user choice

Max: from the github discussion looks like the user also gets a notification...

Dan: Web Audio community have good track record... Also notable that this is multi-stakeholder (Google and Mozilla).

Sangwhan: concern: any API recently minted with a device selector -- firstly it would be a promise... You'd have the UA give a selector.. trying to understand if that pattern exists here or not... The issue opened in 2014... Some legacy elements about implicit device choice in Web Audio API that don't match current patterns.

2022-10-17

Minutes

Max: the author responded to last week's comment and provided information

Dan: it's a compelling argument. Worrying that they're saying there's another feature of another api that would partially solve the problem but it isn't implemented in browsers so that's why they need this. Why isn't in implemented? Maybe it should be deprecated.

Amy: and why would this be implemented in browsers instead?

Dan: they're working on web audio. There's this other thing that's happened in a different WG. That's media capture which is part of webrtc

Max: they also mention in the last sentence - even with that ..

Dan: generally we were happy with this other than that. There is the fact that it has multiple stakeholders.. It does talk about a user need. Privacy review.

<blockquote> Thanks for this review request. We're happy to see this move forward and we're espeicially glad to see it do so with multiple stakeholder support and the attention to privacy considerations. We are slightly concerned that some of the functionality is duplicated elsewhere in the platform, however we undertand the different context. Can you please move the explainer into a markdown file in the appropriate repo? </blockquote>

agreed to close