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

[Bug 17415] (JSWorkers): JavaScriptAudioNode processing in workers

From: <bugzilla@jessica.w3.org>
Date: Thu, 26 Jul 2012 23:42:30 +0000
Message-Id: <E1SuXhO-0005c6-6G@jessica.w3.org>
To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415

--- Comment #54 from Grant Galitz <grantgalitz@gmail.com> 2012-07-26 23:42:29 UTC ---
(In reply to comment #53)
> (In reply to comment #51)
> > 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.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Thursday, 26 July 2012 23:42:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 July 2012 23:42:31 GMT