Re: WebAudio feedback and suggestions

On Thu, Nov 17, 2011 at 10:56 AM, Jonathan Baudanza <jon@jonb.org> wrote:

> On Wed, Nov 16, 2011 at 1:43 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
>> The callback function will still run on the JS main thread, right? (It
>> needs to, to touch the AudioNode objects.) So you'll still glitch when the
>> main thread is running some other script (or doing something else) at that
>> exact moment.
>>
>> In ProcessedMediaStream I solved this problem by having the addInput
>> method take a time parameter (relative to the progress of the output
>> stream, sample-accurate) at which the input stream becomes enabled and
>> unblocks.
>>
>>
> I'm not familiar with ProcessedMediaStream, but it sounds like addInput()
> performs the same function as noteOn(when) on AudioBufferSourceNode.
>

noteOn() is a little different since it can only start playing an
AudioBufferSourceNode, whereas with MediaInput.addInput(when) and
MediaInput.remove(when) ProcessedMediaStreams can schedule arbitrary graph
surgery, but I guess that doesn't help for your use-case.

Scheduling sample accurate playback isn't a problem with the WebAudio
> spec.  The problem is "scheduling the scheduling" of the playback.   For
> some applications you may be able to do all the scheduling upfront.  If
> you're scheduling sounds based on some real time interaction with the user
> (music for example), it's not so simple.  This is where
> context.callbackAtTime comes in.
>

OK, sorry. Unfortunately, what I said about not being able to run script at
specific moments on the main thread is still true. And not only will the
script sometimes not be able to run when you need it to, but it will take
nonzero time to run and you might get a GC or something while it's running,
so you can lose sync that way too.

For the use-case of "I have a really long playlist and I don't want to
schedule it all up-front" (which I think is what
https://bugs.webkit.org/show_bug.cgi?id=70061#c0 is about), I think the
best solution is to use setTimeouts and just make sure that you keep the
playlist up-to-date at least a few seconds ahead of the current time so
that it doesn't under-run.

For interactive stuff, I don't see how running script at a particular
moment in the future helps you. Wouldn't your input event handler directly
schedule whatever new playback elements it needs to trigger?

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgive us
our sins and purify us from all unrighteousness. If we claim we have not
sinned, we make him out to be a liar and his word is not in us." [1 John
1:8-10]