W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

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

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:30:03 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/113/24244626@github.com>
> [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
Received on Wednesday, 11 September 2013 14:38:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:11 UTC