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

Re: Batching WA changes? (Was Re: Audio Workers - please review)

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Fri, 12 Sep 2014 07:38:43 +0300
Message-ID: <CAJhzemVNg9LUOYc0LbJP6ze-v1SEL3YO3ohRZD-ztNfjLbME8g@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Ehsan Akhgari <ehsan@mozilla.com>, Chris Wilson <cwilso@google.com>, Raymond Toy <rtoy@google.com>, Norbert Schnell <Norbert.Schnell@ircam.fr>, "public-audio@w3.org" <public-audio@w3.org>
If we approach this from the perspective of what is acceptable behavior, we
are looking at two options:

1) Blink behavior. You get everything fired ASAP, at the risk of things
scheduled for the same time firing at different times.
2) Gecko behavior. You get everything fired once the HTML5 task finishes,
things scheduled for the same time firing at the same time.

Considering for example a scenario where you schedule two oscilators to
start at the same time to achieve a combination waveform, 2) might get you
latency if the html5 task takes too long, which is unfortunate but
acceptable. However, with 1), even if you take care and start the
oscillators with no actions in between, you might get a phase offset and
thus a completely different waveform. This is completely unacceptable
behavior.
On Sep 12, 2014 6:10 AM, "Robert O'Callahan" <robert@ocallahan.org> wrote:

> On Fri, Sep 12, 2014 at 9:44 AM, Raymond Toy <rtoy@google.com> wrote:
>
>> On Thu, Sep 11, 2014 at 7: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.
>>>
>>
>> I don't understand how this would work. How do you know when to batch up
>> all WA changes?
>> How would this work when you're dynamically creating source nodes and
>> connections?
>>
>
> In Gecko all changes made by a single HTML5 task are grouped into a batch
> and applied atomically when (or more accurately, after, since application
> is async) the HTML5 task ends. ( "Task" is defined in the HTML5 spec. For
> example, the execution of a setTimeout callback is a single HTML5 task.)
>
> And it seems to me that if you wnat node1.start(now) and node2.start(now)
>> to actually start at the same time, don't do expensive things between the
>> two calls to start.  And given the fact that GC can happen at any time,
>> something that wouldn't take a long time may suddenly take a long time.
>>
>> Aren't these things that developers must be aware of in the normal course
>> of operation?
>>
>
> There are some unavoidable issues but this is not one of them. If you take
> the Gecko approach, then if node1.start(N) and node2.start(N) are called in
> the same HTML5 task, they will start playing at exactly the same time
> (after that task ends).
>
> Rob
> --
> oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
> owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
> osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
> owohooo
> osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
> oioso
> oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
> owohooo
> osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
> ooofo
> otohoeo ofoioroeo ooofo ohoeololo.
>
Received on Friday, 12 September 2014 04:39:10 UTC

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