- From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
- Date: Thu, 11 Sep 2014 18:55:48 +0300
- 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>
- Message-ID: <CAJhzemXZZg6Hv8wePB2OSK-j3c19MxQZ+DQQ94A=2=nhO_xdPA@mail.gmail.com>
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 job. 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