W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2011

Re: WebAudio feedback and suggestions

From: Chris Rogers <crogers@google.com>
Date: Wed, 16 Nov 2011 13:24:33 -0800
Message-ID: <CA+EzO0=6pWb6doNUj_AcAS6rjqep5C3erCrLQh4CU_hzca2hSQ@mail.gmail.com>
To: Jonathan Baudanza <jon@jonb.org>
Cc: public-audio@w3.org
On Wed, Nov 16, 2011 at 1:08 PM, Jonathan Baudanza <jon@jonb.org> wrote:

>
>>
>> Is this for cases where you intentionally pass in a time which is already
>> in the past?  Or is it more for the case where you're scheduling times very
>> close to "now" and sometimes one will start rendering a little bit late?
>>
>>
>
> I am thinking about the case where the caller is "close to now" but is a
> little late for some reason (setTimeout inaccuracy perhaps).
>
> I think a caller of noteOn() can have one of two intentions:
>
> 1) The caller wants the sound to start playback immediately, perhaps in
> response to an event like a mouse click or notification.  There should only
> be one way to express this: `source.noteOn()`.  Having
> `source.noteOn(currentTime - someNumber)` available as a way to express
> this isn't really helpful.
>
> 2) The caller wants the buffer played back on a very specific schedule.
> This is probably because the sound must be synchronized with other sounds
> or perhaps something scheduled with callbackAtTime().  In the unfortunate
> event that the caller is late, priority should be given to keeping as much
> of the playback on schedule as possible.  In other words, just because we
> can't play back the beginning of the buffer on schedule, doesn't mean we
> should delay playing back the rest of the buffer on schedule.
>
> I hope I'm explaining this clearly.  If not, I can provide a real world
> example from my beatlab implementation.
>

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.

Chris
Received on Wednesday, 16 November 2011 21:25:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 16 November 2011 21:25:04 GMT