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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#85) by Grant Galitz on W3C Bugzilla. Tue, 31 Jul 2012 03:02:13 GMT

(In reply to [comment #84](#issuecomment-24244771))
> (In reply to [comment #83](#issuecomment-24244765))
> > 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](#issuecomment-24244763))
> > 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.

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