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: Tue, 31 Jul 2012 03:02:14 +0000
Message-Id: <E1Sw2is-0001o6-5A@jessica.w3.org>
To: public-audio@w3.org

--- Comment #86 from Grant Galitz <grantgalitz@gmail.com> 2012-07-31 03:02:13 UTC ---
(In reply to comment #84)
> (In reply to comment #83)
> > Can we add callbacks for when a buffer is done playing?
> No, because they will fire too late for you to queue the next buffer and get
> seamless playback.
> (In reply to comment #82)
> > I seriously don't like the idea of using setInterval callbacks to drive the
> > callback procedure instead of an actual callback derived from the audio clock.
> You're going to have to schedule timeouts early anyway to maximise the chance
> that your callback runs in time to schedule the next buffer seamlessly, so
> accuracy doesn't matter, so using the audio clock instead of the system clock
> doesn't matter since there will be negligible drift over the intervals we're
> talking about.

I would be listening on a supposed finish event of buffers ahead of the last
one scheduled. One wouldn't wait until the system is dry to refill. I'm talking
about firing events for multiple buffers queued, so that if we run past a low
point in the queue, we can prep and load new buffers. Using setInterval timers
is not fool proof here, as some browsers that may implement the web audio api
spec might not allow high res js timers. Numerous browsers either clamp heavily
or have too much timer jitter (Opera people, I'm looking at you with that timer
jitter on os x...).

crogers: I see what you're getting at. I'm just trying to make sure we all
understand the audio input from the js side can be blocked inside a worker or
on the main thread either way. Slow JS is slow JS.

Also how would sleep events interact with the currentTime counting? Would it be
paused or would it clock with the computer's time system? For the audio to be
foolproof it requires pure time clocking from the audio card/chip (So sleep
events would pause it), otherwise audio buffering state can be thrown off by
time changes or sleep events.

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 Tuesday, 31 July 2012 03:02:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:11 UTC