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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#75) by Grant Galitz on W3C Bugzilla. Sun, 29 Jul 2012 16:56:03 GMT

(In reply to [comment #75](#issuecomment-24244735))
> (In reply to [comment #69](#issuecomment-24244713))
> > No, 0.5 seconds is trash. Needs to be no worse than 100 ms or it sounds like
> > poop to the user.
> 
> Obviously. I meant it more as an exercise: How low can you practically go? (out
> of curiosity)

Doesn't matter, because we would not be continuing from the previous stream, and the lack of audio clock. Firing sample buffers based on time rather than audio clock is something I would never do. I'd rather pipe in audio to the web worker and force the users of browsers that have to do that experience high copy overhead for the piping with the audio lag. I'd always rather deal with crazy audio lag than arbitrarily schedule new audio that's not driven from previous stream endings.

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