3 ms·

An `AudioContext` (which is the object that lets you do non-trivial audio in the browser) does most of its work on a special, high priority thread, off an audio

by padenot 10y ago

An `AudioContext` (which is the object that lets you do non-trivial audio in the browser) does most of its work on a special, high priority thread, off an audio callback. Having `AudioContext` in a worker does not get you a lot. It's planned, but not prioritized very high. What happens when you're calling methods in JavaScript on an `AudioContext` is that we simply validate the input and queue messages to the audio thread, so this is effectively exactly what the article is talking about. We use some locking, but we've carefully wrote the code so that it's not really an issue. We lock just to swap two pointers in a message queue. This could certainly use atomics, but we have more important things to do first. That said, the interesting thing developers need and want is `AudioWorklets` [0], and that's what we at the W3C Audio WG is working on more or less full-time, these days. It used to be called `AudioWorker`, but got renamed for a lot of reasons [1]. [0]: https://github.com/WebAudio/web-audio-api/wiki/AudioWorklet-IDL-Proposal https://github.com/WebAudio/web-audio-api/wiki/AudioWorklet-... [1]: https://github.com/WebAudio/web-audio-api/issues/532 https://github.com/WebAudio/web-audio-api/issues/532

fenomas 10y ago
Thanks, this is very useful! Follow up questions, if you see them: 1. Does what you said include ScriptProcessorNodes? 2. Is this true of all browsers per specification, or true of a particular browser's implementation? My experience with web audio has been that in Chrome things work as you say, but in FF I could never find a webaudio library that played back without heavy clicking, so I supposed audio workers might help. 3. Given what you said, what will be different about Worklets? I scanned the links but I guess I don't follow the bigger picture.
- padenot 10y ago
  1. No, it's the one thing that has to be on the main thread per spec. 2. It's true for all browsers. ScriptProcessor runs on the main thread and can be glitchier in Firefox (but depending on the use case it can be the opposite). See https://padenot.github.io/web-audio-perf/#scriptprocessornode https://padenot.github.io/web-audio-perf/#scriptprocessornod... for more details. 3. Worklets are bits or javascript that run on the audio thread directly, where you're supposed to only implement the DSP bits, and only communicate with the main thread using message passing.

by padenot 10y ago

fenomas 10y ago

Thanks, this is very useful! Follow up questions, if you see them: 1. Does what you said include ScriptProcessorNodes? 2. Is this true of all browsers per specification, or true of a particular browser's implementation? My experience with web audio has been that in Chrome things work as you say, but in FF I could never find a webaudio library that played back without heavy clicking, so I supposed audio workers might help. 3. Given what you said, what will be different about Worklets? I scanned the links but I guess I don't follow the bigger picture.

padenot 10y ago
1. No, it's the one thing that has to be on the main thread per spec. 2. It's true for all browsers. ScriptProcessor runs on the main thread and can be glitchier in Firefox (but depending on the use case it can be the opposite). See https://padenot.github.io/web-audio-perf/#scriptprocessornode https://padenot.github.io/web-audio-perf/#scriptprocessornod... for more details. 3. Worklets are bits or javascript that run on the audio thread directly, where you're supposed to only implement the DSP bits, and only communicate with the main thread using message passing.