web-audio-api

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

Hey! I'm head of audio and MIDI at Flat. In fact, latency and audio quality (because of file sizes for sampling and because of available resources for synthesis) are two big limitations in a browser. We have big expectations about the upcoming Audio Workers ( https://github.com/WebAudio/web-audio-api/issues/113 ) to release advanced synthesizer. Also, we want to enjoy the capabilities of the MIDI output features, in order to route MIDI signals to Virtual Instruments on the computer (through virtual MIDI ports)