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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#70) by Grant Galitz on W3C Bugzilla. Fri, 27 Jul 2012 16:44:12 GMT

(In reply to [comment #61](#issuecomment-24244659))
> (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.

Make a mozAudio like access to the API for the main thread. Only sync up when the main thread pushes new audio or requests for the buffering amount. Firefox is known to play samples even through GC pauses with mozAudio. It allows the js dev to pass samples to the browser AND let the browser handle the buffering for it as well without issuing callbacks.

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

Received on Wednesday, 11 September 2013 14:38:15 UTC