AudioContext.setSinkId() #2498
AudioContext.setSinkId() #2498
Conversation
|
@padenot PTAL - I've made an attempt on setSinkId() based on our discussion. I'll add |
This implements: WebAudio/web-audio-api#2498 sinkId and setSinkId are added to support selecting an audio output device. setSinkId() will take in sinkId as a DOMString and return a pending promise. This CL adds IDL / attribute / method for setSinkId and will be gated behind AudioContextSetSinkId/test. Related CL: 3838685 Reference document: go/webaudio-setsinkid-api Bug: 1216187 Change-Id: I001743125bbf0dce8104c23d34f10d33fb562f48 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3862684 Reviewed-by: Hongchan Choi <[email protected]> Reviewed-by: Philip Rogers <[email protected]> Commit-Queue: Alvin Ji <[email protected]> Cr-Commit-Position: refs/heads/main@{#1042229}
This implements: WebAudio/web-audio-api#2498 sinkId and setSinkId are added to support selecting an audio output device. setSinkId() will take in sinkId as a DOMString and return a pending promise. Multiple setSinkId requests are queued and resolved sequentially. Reference document: go/webaudio-setsinkid-api Bug: 1216187 Change-Id: I4125a0b434b45a9364cf1a69ad9b858a6d6fb7a4 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3838685 Reviewed-by: Hongchan Choi <[email protected]> Commit-Queue: Alvin Ji <[email protected]> Cr-Commit-Position: refs/heads/main@{#1046125}
Since we probably are going to use "statechange" to suspend/resume rendering, so that already implicates the operation boundary is based on render quantum. What do you think?
I think it's better to limit Re: the proposal we discuss in TPAC 2022:
Yes. This is handled by the prose "run a control message...".
This is reasonable, but will trigger two
Also reasonable, and in the spec I think we can simply say "when the system-level audio callback is invoked from the new audio stream". It's useful that we already defined: https://webaudio.github.io/web-audio-api/#system-level-audio-callback |
|
PTAL again @padenot and @chrisguttandin - I think the last revision covers what @padenot suggested in #2498 (comment). |
There was a problem hiding this comment.
Thanks for pinging me again. I only spotted a few "tabs".
While reading the text I was wondering what would be the sampleRate of an AudioContext with { type: 'none' } as the sinkId? Do we need to define a default sampleRate for that case?
const audioContext = new AudioContext({ sinkId: { type: 'none' } });
console.log(audioContext.sampleRate); // ?I was also wondering if the algorithm for changing the output device should be aborted if the the device doesn't change. As far as I understand it the following code (which is of course a silly example) would still trigger the algorithm although it's basically not changing anything.
audioContext.setSinkId(audioContext.sinkId);
|
@chrisguttandin The {type: "none"} is handled by the step below:
For your second question, I think the "do nothing" case only happens when |sinkId| is the same with the current one. All other case will be handled by the rejected promise. What do you think? |
|
Since I often run the Web Audio API in tests on CI servers I had to learn the hard way that not every computer (or VM) has an audio device. :-( I'm not sure though if that rare edge case needs to be handled. I think you're right, the second question can probably be ignored. Calling |
|
Hmm. That's an interesting case - but it easily leads into a different question. setSinkId() won't even be a problem because the AudioContext construction will fail on such system. IMO it needs a new spec issue for further discussion. |
|
@padenot While cleaning up and preparing for mark up, I made some changes to improve the algorithm:
Other than that changes are editorial. Please feel free to take one more look - in the mean time I'll start marking things up for landing. |
|
Okay, the markup is done and this PR is ready to land. |
Changes in WebAudio#2498 introduce a weird phrasing for "fire an event", e.g. "Fire an event to onstatechange EventHandler". Correct phrasing should rather be "Fire an event named statechange". This made me realize that the spec never associates the event handler IDL attributes that it defines with the actual event handler event type that gets fired. The spec also seems to assume that there will be at most one event handler (e.g. when it says that "This AudioBuffer is only valid while in the scope of the onaudioprocess function"), whereas `onxxx` is just one way to listen to `xxx` events, `addEventListener` may also be used. Specs typically make the association between event handler IDL attributes and event handler event types explicit, e.g. as done in HTML through tables such as: https://html.spec.whatwg.org/multipage/webappapis.html#event-handlers-on-elements,-document-objects,-and-window-objects ... or in WebRTC through text in the definition of the IDL attribute: https://w3c.github.io/webrtc-pc/#ref-for-event-datachannel-bufferedamountlow-1 This pull request adds definitions of event types next to the definitions of the `onxxx` IDL attributes with which they are associated and uses references to these event types whenever the spec fires an event or mentions event handlers. I tried to keep the changes minimal. I was going to argue that these changes are editorial in nature as they merely clarify something that did not create ambiguities for implementations. Now, you seem to track all changes with "proposed corrections", regardless of whether they're editorial or substantive so I suspect you cannot accept these changes as-is... At a minimum, I think that the occurrences of "fire an event to onxxx" should be fixed (they only appear in proposed corrections so that seems doable without creating additional proposed corrections). I can prepare a separate PR to that effect. I can also look into creating appropriate "proposed corrections" structures for the other changes if they seem useful. That may not be worth the hassle.
Changes in WebAudio#2498 introduce a weird phrasing for "fire an event", e.g. "Fire an event to onstatechange EventHandler". Correct phrasing should rather be "Fire an event named statechange". This made me realize that the spec never associates the event handler IDL attributes that it defines with the actual event handler event type that gets fired. The spec also seems to assume that there will be at most one event handler (e.g. when it says that "This AudioBuffer is only valid while in the scope of the onaudioprocess function"), whereas `onxxx` is just one way to listen to `xxx` events, `addEventListener` may also be used. Specs typically make the association between event handler IDL attributes and event handler event types explicit, e.g. as done in HTML through tables such as: https://html.spec.whatwg.org/multipage/webappapis.html#event-handlers-on-elements,-document-objects,-and-window-objects ... or in WebRTC through text in the definition of the IDL attribute: https://w3c.github.io/webrtc-pc/#ref-for-event-datachannel-bufferedamountlow-1 This pull request adds definitions of event types next to the definitions of the `onxxx` IDL attributes with which they are associated and uses references to these event types whenever the spec fires an event or mentions event handlers. I tried to keep the changes minimal. I was going to argue that these changes are editorial in nature as they merely clarify something that did not create ambiguities for implementations. Now, you seem to track all changes with "proposed corrections", regardless of whether they're editorial or substantive so I suspect you cannot accept these changes as-is... At a minimum, I think that the occurrences of "fire an event to onxxx" should be fixed (they only appear in proposed corrections so that seems doable without creating additional proposed corrections). I can prepare a separate PR to that effect. I can also look into creating appropriate "proposed corrections" structures for the other changes if they seem useful. That may not be worth the hassle.
Changes in #2498 introduce a weird phrasing for "fire an event", e.g. "Fire an event to onstatechange EventHandler". Correct phrasing should rather be "Fire an event named statechange". This made me realize that the spec never associates the event handler IDL attributes that it defines with the actual event handler event type that gets fired. The spec also seems to assume that there will be at most one event handler (e.g. when it says that "This AudioBuffer is only valid while in the scope of the onaudioprocess function"), whereas `onxxx` is just one way to listen to `xxx` events, `addEventListener` may also be used. Specs typically make the association between event handler IDL attributes and event handler event types explicit, e.g. as done in HTML through tables such as: https://html.spec.whatwg.org/multipage/webappapis.html#event-handlers-on-elements,-document-objects,-and-window-objects ... or in WebRTC through text in the definition of the IDL attribute: https://w3c.github.io/webrtc-pc/#ref-for-event-datachannel-bufferedamountlow-1 This pull request adds definitions of event types next to the definitions of the `onxxx` IDL attributes with which they are associated and uses references to these event types whenever the spec fires an event or mentions event handlers. I tried to keep the changes minimal. I was going to argue that these changes are editorial in nature as they merely clarify something that did not create ambiguities for implementations. Now, you seem to track all changes with "proposed corrections", regardless of whether they're editorial or substantive so I suspect you cannot accept these changes as-is... At a minimum, I think that the occurrences of "fire an event to onxxx" should be fixed (they only appear in proposed corrections so that seems doable without creating additional proposed corrections). I can prepare a separate PR to that effect. I can also look into creating appropriate "proposed corrections" structures for the other changes if they seem useful. That may not be worth the hassle.
Fixes: #2400
Preview | Diff