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

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

--- Comment #10 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> 2012-06-13 15:42:55 UTC ---
(In reply to comment #8)
> (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?

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

-- 
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 15:43:03 UTC