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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#7) by Philip Jägenstedt on W3C Bugzilla. Wed, 13 Jun 2012 09:59:16 GMT

(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?

> > I'm fairly certain it would fail horribly in Opera, as other pages running in
> > the same process can't be expected to write code to avoid long-running scripts
> > or expensive re-layouts.
> 
> Of course, it's impossible to predict what's going on other pages, but that
> applies to drawing and other things as well, to achieve the best results, users
> have to close other tabs unless the browser has some multi-threading going on
> with different tabs.
> 
> But I beg to differ that Opera would fail horribly. In my sink.js [1] (a
> library to allow raw access to audio cross-browser), I have a fallback using
> the audio tag, you can take a look at an example of how it runs on Opera here
> [2] (a demo I made for last Christmas). The result is bearable, even though wav
> conversion and data URI conversion sucks the CPU dry. There are glitches every
> 0.5s or so, due to switching the audio tag but that's only because the onended
> event triggering the next clip fires a significant time after the audio has
> actually finished playing.
> 
> [1] https://github.com/jussi-kalliokoski/sink.js
> [2] http://audiolibjs.org/examples/bells.html

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.

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