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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#28) by Robert O'Callahan (Mozilla) on W3C Bugzilla. Tue, 19 Jun 2012 23:15:33 GMT

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

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