Re: WebAudio feedback and suggestions

On Wed, Nov 16, 2011 at 2:11 PM, Jonathan Baudanza <jon@jonb.org> wrote:

>
>
> On Wed, Nov 16, 2011 at 1:24 PM, Chris Rogers <crogers@google.com> wrote:
>
>
>> Jonathan, thanks for the explanation.  I'm pretty sure I understand what
>> you mean here.  Ideally, we would never see this "unfortunate event" and
>> all events would be scheduled sufficiently in advance (at least ~100ms),
>> but your solution seems like the right approach if the event "misses"
>> because it is scheduled too close to "now".  It may be worth considering an
>> attribute which can control this behavior, so we can control how this works.
>>
>>
> Yes having callbackAtTime() available should significantly mitigate this
> "unfortunate event".  I imagine it will still happen when implementers
> naively use setTimeout or the thread is blocked by a window.alert or some
> long running loop.  The audio playback will glitch but it would be nice if
> the API recovered nicely.
>

There's always the chance that the callback will get called back late
because the main thread is busy doing something else (gc, page-rendering,
running other JS).  That's why it's important to make sure you don't try to
callback too "soon" into the future, or you'll risk getting the callback
late.  Luckily, for most sequencing applications  it's almost always
possible to schedule events at least 50ms or 100ms (or so) into the future
and avoid these kind of problems.  By the way, it's not really an audio
"glitch" that occurs if the callback is late, it's just that the event gets
handled late, resulting in a note playing a bit late, for example.

Chris