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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#60) by Marcus Geelnard (Opera) on W3C Bugzilla. Fri, 27 Jul 2012 07:54:13 GMT

(In reply to [comment #52](#issuecomment-24244617))
> There's always some lag with comm to a webworker, and losing the direct ability
> to be called for refill on the same thread for audio makes the entire web app
> vulnerable to lag spikes in webworker communication. I saw this with the
> MediaStream API, where sync backs would be bunched up too much causing too much
> inconsistency and thus gaps.

I haven't looked into the worker communication lag part, but I don't really see a fundamental reason why it has to be a problem.

On the other hand, doing audio callbacks on the main thread will always be problematic, and I don't see how it could ever be solved. I envision a design where the audio mixer is running in a separate thread (or possibly multiple threads for graphs with independent processing chains). Whenever a node is encountered that needs data from a main thread callback, the mixing thread will have to halt and wait until the main thread callback has fired and finished, which is very sensitive to other things that may be going on in the main thread (e.g. a setInterval/requestAnimationFrame event).

I'd much more prefer a solution that does not require the audio mixing thread to be halted just to fire an event on the main thread.

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