[Bug 17415] (JSWorkers): JavaScriptAudioNode processing in workers

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415

--- Comment #8 from Philip J <philipj@opera.com> 2012-06-13 09:59:16 UTC ---
(In reply to comment #7)
> > 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.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Wednesday, 13 June 2012 09:59:19 UTC