Re: Web Audio API sequencer capabilities

On Wed, Aug 22, 2012 at 10:04 AM, rl baxter <baxrob@gmail.com> wrote:

> Hello all,
>
> This reminded me:
>
> 1. Speaking of sequence event timing, the idea of a callbackAtTime
> method has been raised, though not much discussed AFAIK.  At least,
> maybe this webkit bug report should be ported to the w3 tracker:
> https://bugs.webkit.org/show_bug.cgi?id=70061 .
>   This idea speaks volumes to me because there is currently no way to
> schedule arbitrary events in sync with the audio clock (the closest
> thing is firing an event in the jsNode.onaudioprocess loop, but that
> can only be accurate to within the time-grain of its buffer size).
>

Yes, this is an idea that needs some thought. There are some problems with
the callbackAtTime approach, namely of when should the event occur in
relation to the audio clock time specified. For example, you have a sound
that needs to be set up at a certain time. If you set the callback at the
time when the sound is supposed to play, does it occur before, after or
exactly (I doubt it) when the audio clock is at that specified time? If it
occurs after, the sound will miss its cue. If it occurs before, how much
before (if it happens after, the delay is justifiable by the thread
latencies and event loop priorities)? Will the "how much before" be enough
to schedule the note anyway if for example a drawing operation is happening
at the time the callback is supposed to happen?


> 2. Re: "breaking changes".  They will only become more breaking, no?
> It'd be least harmful to incorporate any glaringly necessary ones as
> soon as possible.  For example, it seems clear that
> JavascriptAudioNode calls for severe re-thinking.
>

Indeed, and I believe this change would be one worth making. The gain can
be easily quantified to solve problems (as opposed to things like rename
this to that) and aside from it being a change, no downsides have been
raised yet.

Cheers,
Jussi