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

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415#81) by Grant Galitz on W3C Bugzilla. Mon, 30 Jul 2012 16:14:46 GMT

(In reply to [comment #81](#issuecomment-24244762))
> (In reply to [comment #59](#issuecomment-24244648))
> > AFAICT, the noteOn & AudioParam interfaces were designed for making it possible
> > to schedule sample accurate audio actions ahead of time. I think that it
> > *should* be possible to use it for providing gap-less audio playback (typically
> > using a few AudioBuffers in a multi-buffering manner and scheduling them with
> > AudioBufferSourceNodes). The problem, as it seems, is that you need to
> > accommodate for possible jittering and event drops, possibly by introducing a
> > latency (e.g, would it work if you forced a latency of 0.5s?).
> 
> I think a solution that uses setInterval() to schedule frequent JS callbacks,
> checks AudioContext.currentTime to measure the progress of the audio clock, and
> uses AudioBufferSourceNodes to queue playback of generated audio buffers,
> should work as well as any other, providing the Web Audio implementation is
> adequate. Incremental GC might also be required.

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. I thought we were about reducing power consumption as well? Deriving callbacks from the audio clock means we don't waste checks with setInterval, as we'd need to run setInterval faster than the buffer scheduling rate versus at the rate for an audio clock derived callback. I still don't like the idea of driving with a float based timestamp, I feel chills from possible implementation errors, and one off errors.

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