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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#29) by Jussi Kalliokoski on W3C Bugzilla. Wed, 20 Jun 2012 01:14:21 GMT

(In reply to [comment #29](#issuecomment-24244480))
> (In reply to [comment #26](#issuecomment-24244453))
> > 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.
> 
> With JS audio produced in Workers, the browser should be able to make audio
> work reliably in any situation short of complete overload of the device.
> 
> With JS audio on the main thread, audio will start failing as soon as a
> badly-behaving page happens to share the same main thread as the audio page.
> 
> That is a huge difference.
> 
> > 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.
> 
> For use-cases such as "run an emulator producing sound and graphics", the best
> solution is to provide Worker access to canvas as well as audio. Then you can
> have reliable audio and a reliable frame rate as well.
> 
> Are there any other use-cases that are problematic for audio production in
> Workers?

If Workers get access to canvas, at least I can't think of a (valid) reason why anyone would want to process audio in the main thread. :)

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