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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#35) by Grant Galitz on W3C Bugzilla. Mon, 09 Jul 2012 02:36:50 GMT

An even bigger blocker for me actually is the keyboard events. I cooked up a webworker based version of JS GBC long ago and noticed at the time that I had to pass keyboard event notifications to the webworker, causing one to experience lag with input as well. It's the being forced to pipe so much from the UI to the worker that makes webworker usage for my case entirely pointless at the moment. A webworker is going to need access to almost as many APIs as the main thread if we're going to perform real time processing with low latency that involves various forms of dynamic input. Adding thousands of lines of code to make a single-threaded application perform worse in a web worker versus the UI thread seems silly to me.

Also the UI thread being blocked from other tabs is experienced on a per-browser basis for me at least, with Chrome in the clear actually. I do experience things like js timers dropping from 4 ms to 500 ms intervals when I do things like try to hover over the mac os x dock or change the volume, so forcing multi-tasking within the js environment via workers seems like the "fix" for firefox at least.

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