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:
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