Re: WebAudio feedback and suggestions

On Wed, Nov 16, 2011 at 12:32 PM, Chris Rogers <crogers@google.com> wrote:

>
> Is this something which can be addressed by CORS?
>

Yes, it is. Jussi pointed this out last night.  Unfortunately, Amazon S3
doesn't support CORS headers, so I'll have to stick with the IFRAME hack
for now.  This is an issue with S3 though, not the Web Audio spec.


>
> This isn't exactly the same as what Joe proposed, but we're looking at a
> solution which is somewhat better than setTimeout():
> https://bugs.webkit.org/show_bug.cgi?id=70061
>
>
This looks perfect.


>
> 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.