W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2014

Re: Audio Workers - please review

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Thu, 11 Sep 2014 18:55:48 +0300
Message-ID: <CAJhzemXZZg6Hv8wePB2OSK-j3c19MxQZ+DQQ94A=2=nhO_xdPA@mail.gmail.com>
To: Chris Wilson <cwilso@google.com>
Cc: Norbert Schnell <Norbert.Schnell@ircam.fr>, Ehsan Akhgari <ehsan@mozilla.com>, "public-audio@w3.org" <public-audio@w3.org>
On Thu, Sep 11, 2014 at 5:51 PM, Chris Wilson <cwilso@google.com> wrote:

> I don't know how it is possible to do this, unless all WA changes are
> batched up into a single postMessage.

I think that would be beneficial, yes. The same applies to native nodes -
in most web platform features (in fact I can't think of one exception) the
things you do in a single "job" get *observably* applied at the same time,
e.g. with WebGL you don't get half the scene rendered in one frame and the
rest in the next one. This is the point argued in earlier discussions some
time ago as well: the state of things shouldn't change on its own during a

As for the creation of the audio context, I think the easiest solution is
that we specify that the context starts playback only after the job that
created it has yielded, batching up all the creation-time instructions
before starting playback.

> On Thu, Sep 11, 2014 at 4:41 PM, Norbert Schnell <Norbert.Schnell@ircam.fr
> > wrote:
>> On 11 sept. 2014, at 15:41, Chris Wilson <cwilso@google.com> wrote:
>> > I think this is actually indefinite in the spec today - and needs to
>> be.  "start(0)" (in fact, any "start(n)" where n is <
>> audiocontext.currentTime) is catch as catch can; thread context switch may
>> happen, and that needs to be okay.  Do we guarantee that:
>> >
>> > node1.start(0);
>> > ...some really time-expensive processing steps...
>> > node2.start(0);
>> > will have synchronized start times?
>> IMHO, it would be rather important that these two really go off at the
>> same time :
>> var now = audioContext.currentTime;
>> node1.start(now);
>> ...some really time-expensive
>> node2.start(now);
>> ... unless we can well define what "really time-expensive" means and the
>> ability to avoid it.
>> Is that actually case? I was never sure about this...
>> Evidently it could be sympathetic if everything <
>> audioContext.currentTime could just be clipped and behave accordingly. That
>> would make things pretty clear and 0 synonymous to "now", which feels right.
>> Norbert
Received on Thursday, 11 September 2014 15:56:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:14 UTC