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

Re: WebAudio feedback and suggestions

From: Jonathan Baudanza <jon@jonb.org>
Date: Wed, 16 Nov 2011 15:14:05 -0800
Message-ID: <CAP26MZvVO_exeCR5rUKNNw+oes7oXF0NXk7BFOQ3EDRXC4hbTw@mail.gmail.com>
To: public-audio@w3.org
On Wed, Nov 16, 2011 at 2:08 PM, Robert O'Callahan <robert@ocallahan.org>wrote:


> 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?
>
>
Just for reference, my app is www.beatlab.com.  In my webaudio branch, I
have a setTimeout callback set at 100ms intervals.  At each interval it
checks if there is a note coming up, and schedules it.  If setTimeout
doesn't fire for some reason, sounds aren't scheduled properly.

I think what you're suggesting is that I schedule all my audio nodes at the
beginning of a loop, and then add and remove nodes from the schedule as the
user interacts with the application.  I don't see any reason why this
wouldn't work.  The downside is that I would have a lot more audio nodes to
manage.  The advantage is I wouldn't have to depend on a callback firing at
the right time.
Received on Wednesday, 16 November 2011 23:14:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 16 November 2011 23:14:46 GMT