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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415

--- Comment #82 from Grant Galitz <grantgalitz@gmail.com> 2012-07-30 16:14:46 UTC ---
(In reply to comment #81)
> (In reply to comment #59)
> > 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.

-- 
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 Monday, 30 July 2012 16:14:55 UTC