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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#25) by Jussi Kalliokoski on W3C Bugzilla. Tue, 19 Jun 2012 15:08:43 GMT

(In reply to [comment #25](#issuecomment-24244446))
> (In reply to [comment #23](#issuecomment-24244435))
> > (In reply to [comment #21](#issuecomment-24244423))
> > Of course, but this argument is just as valid against having an audio API at
> > all, after all the developer can't anticipate what else is running on the
> > user's computer aside from the browser. For all the developer knows, the API
> > might be running on a mobile browser with all cores (or maybe just one) busy.
> > Throwing more threads at it doesn't necessarily solve the problem of not being
> > able to anticipate all situations.
> 
> True, but there is a significant difference between running several threads on
> a single core (preemptive scheduling should give any thread CPU quite often),
> and running several pages in a single thread (a callback may have to wait for
> seconds).

Still, no matter what we do, in some cases audio will not work as expected, will miss refills, and there's nothing we can do about it. What we can do, however, is give the proper tools to handle these situations, including main thread audio processing that doesn't have to resort to manually transferring audio to a worker (or graphics to the main thread either), because that's even more expensive and likely to fail.

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