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

Behavior 2 is consistent with other web APIs I have used, especially ones
where you say "start", then add callbacks. No events can get lost since
nothing starts in the background until you are through with the task.


Adam

On Fri, Sep 12, 2014 at 12:38 AM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:

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