Re: Audio Workers - please review

Actually, I believe I completely misspoke.  I believe postMessages are only
dispatched from a thread when the originating thread "has time" - e.g. "The
window.postMessage method, when called, causes a MessageEvent to be
dispatched at the target window when any pending script that must be
executed completes (e.g., remaining event handlers if window.postMessage is
called from an event handler, previously-set pending timeouts, etc.)" (from
https://developer.mozilla.org/en-US/docs/Web/API/Window.postMessage).  So
these would process in order, and be dispatched at the same time.

On Thu, Sep 11, 2014 at 5:55 PM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:

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