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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#11) by Jussi Kalliokoski on W3C Bugzilla. Wed, 13 Jun 2012 18:07:28 GMT

(In reply to [comment #11](#issuecomment-24244356))
> Not quite the same thing as audio processing, but we're trying to limit
> all the new XHR features in main thread to async only. Sync is occasionally
> easier
> to use, but it will just fail (cause bad user experience) in the main thread.
> (And yes, the change to limit certain sync behavior to workers only broke
> various libraries.)
> 
> Similarly, JS audio processing is guaranteed to fail on the main thread
> in reasonable common cases. So, IMHO, all the JS audio processing
> should happen in background threads.

I agree it should, but I don't think it will. What should an emulator/VM developer do? Render off main-thread as well? MSP API would have been a perfect fit for that use case, given it's ability to process video as well... Analyzing the byte code of those existing games and other programs and isolating the audio code to another thread doesn't sound very feasible.

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