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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#53) by Grant Galitz on W3C Bugzilla. Thu, 26 Jul 2012 23:42:29 GMT

(In reply to [comment #53](#issuecomment-24244623))
> (In reply to [comment #51](#issuecomment-24244611))
> > Option 1 does not make the situation for gapless audio any better here. We're
> > just making it harder to push out audio. The browser knows best when to fire
> > audio refills. Forcing the JS code to schedule audio will make audio buffering
> > and drop outs worse.
> 
> I don't follow this. You're already using some JS scheduling to drive the
> progress of the emulator (requestAnimationFrame? setInterval?). Each step of
> the emulator generates some audio samples that you want to play back as soon as
> possible. So stuffing those samples into an output pipe somehow should be good
> for you.
> 
> Or are you actually trying to drive the progress of the emulator off the audio
> clock somehow?

I drive off both. I use the audio clock and setInterval. If I used setInterval, almost every browser wouldn't run the code enough, so the right thing to do is to drive with the audio clock in addition to the setInterval.

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