Re: [web-audio-api] (JSWorkers): ScriptProcessorNode processing in workers (#113)

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#9) by Jussi Kalliokoski on W3C Bugzilla. Wed, 13 Jun 2012 15:42:55 GMT

(In reply to [comment #8](#issuecomment-24244330))
> (In reply to [comment #7](#issuecomment-24244322))
> > > That's not how a worker-based AudioNode would work, it would be a callback in
> > > the worker that can read directly from the input and write directly to the
> > > output.
> > 
> > Exactly, and if the audio processing takes place in the main thread, you have
> > no way of knowing when the callbacks in the worker occur. Hence you have to
> > devise your own callback system to sync with the one going on in the worker,
> > and send data over to the worker using postMessage, being a very ineffective
> > solution for a case that's already very vulnerable. Not to mention that it's
> > difficult to implement without ending up with weird edge-case race conditions.
> 
> The solution is to not do audio processing in the main thread and to post the
> state needed to do it in the worker instead. This seems trivial to me, do you
> have a real-world example where it is not?

No, I'm afraid I don't, and there probably aren't too many around (anymore, developers know better these days). But the emulator case still stands, there are already emulator environments written in JS. [1] [2] [3] [4]

> That's really cool, but not at all the same. If you generate 500 ms second
> chunks of audio, blocking the main thread with layout for 100 ms is not a
> problem. With the current JavaScriptAudioNode the block size can go as small as
> 256, which is only 5 ms at 48Khz. To never block the main thread for more than
> 5 ms is not a guarantee we can make.

Obviously the developers need to adjust their buffer sizes to work in the main thread, buffer sizes of 256 samples in the main thread with JS are (for now) a bit unrealistic — given the complexity and threading that comes with this API — and fails currently in Chrome as well (although I'm not sure why, the CPU usage is only 2% or so, but I suppose this is a thread communication latency issue), in fact any buffer size under 2048 makes the JSNode glitch horribly. If the developer expects her application to work in a mobile phone as well, she'll have to adjust that buffer size further. Indeed, I once proposed that the buffer size argument of the JSNode would be optional so that the browser could make a best approximation of what kind of a buffer size could be handled on a given setup. [5]

It's not like we can prevent people from doing their audio processing in the main thread. What we can do, however, is give them proper tools to do that in a minimally disruptive way for the user experience.

[1] http://fir.sh/projects/jsnes/
[2] http://gamecenter.grantgalitz.org/
[3] http://www.kingsquare.nl/jsc64
[4] http://bellard.org/jslinux/ (has no use case for audio - yet)
[5] http://lists.w3.org/Archives/Public/public-audio/2012AprJun/0106.html

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/113#issuecomment-24244348