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

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

(In reply to [comment #39](#issuecomment-24244535))
> (In reply to [comment #38](#issuecomment-24244528))
> > To sum up my argument: We are currently not provided all the resources inside a
> > webworker to attain full independence from the main thread yet, and dependence
> > on the main thread kills us with i/o lag.
> 
> A possible solution for emulators like the JS GBC emulator (which I really
> like!): move the audio emulation part to a Web worker (making it independent
> from the main thread), and post time-stamped audio HW register writes from the
> main thread to the audio Web worker (should be quite compact data?). That way
> you would be glitch free even in cases of i/o lag. This assumes that you can do
> the audio HW emulation independently from the rest of the machine, but for
> simple "8-bit" sound HW, I think it can easily be done.

One possible problem with that is we would need to synchronize up to once every two clocks at a sample rate of 4194304 hertz (One sample per clock cycle for LLE emulation). We also would need to synchronize back part of the audio state, as we expose some of the state back in the emulated hardware registers.

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