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

Re: Audio Workers - please review

From: Ehsan Akhgari <ehsan@mozilla.com>
Date: Thu, 11 Sep 2014 12:33:00 -0400
Message-ID: <CANTur_4RyY88APF5-YbMfzhQ2qNAxnv7TP6kTCj+HPDC8nEqjQ@mail.gmail.com>
To: Chris Wilson <cwilso@google.com>
Cc: Norbert Schnell <Norbert.Schnell@ircam.fr>, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, "public-audio@w3.org" <public-audio@w3.org>
On Thu, Sep 11, 2014 at 10:51 AM, 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.
>

Yep, that would be how you'd implement it.  This is how sending all other
arguments to the audio worker is currently implemented in Gecko, for
example.  (Not sure about WebKit/Blink.)


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


-- 
Ehsan
Received on Thursday, 11 September 2014 16:34:14 UTC

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