W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2015

Re: Processing Model

From: Paul Adenot <padenot@mozilla.com>
Date: Mon, 5 Oct 2015 16:37:41 +0200
Message-ID: <CANWt0WoL0NqnAz_WCjAFGJAZmPgUG7kCeLxcnCGPu91-8mWuVg@mail.gmail.com>
To: Joe Berkovitz <joe@noteflight.com>
Cc: Audio Working Group <public-audio@w3.org>
Replies inline.

On Fri, Oct 2, 2015 at 9:20 PM, Joe Berkovitz <joe@noteflight.com> wrote:

> [chair hat off]
>
> Hi Paul,
>
> I'm beginning to review your changes and wanted to start with  the
> processing model. I think it's an really important section and I'm glad you
> made this. I think the concepts make sense.
>
> Leaving wordsmithing aside for later, I have a couple of observations:
>
> - There is some confusion/conflation between "messages" and "operations"
> and "methods". In 3.3 you say, "calling methods on nodes must be done in
> two phases, sync and async". Then you proceed to talk about how the sync
> and async part of operations (not methods) are ordered. And later you talk
> about the "asynchronous section of a message" in 3.4.
>

> I think it's necessary to explain this by connecting the terms more
> explicitly. Methods invoke operations. The sync part of an operation then
> executes immediately; following that (if successful), a control message
> encodes the async part of the operation and is enqueued, to be picked up by
> a rendering thread.... IIRC.
>
> I have a feeling that it will be useful to sometimes define operations
> separately from methods.
>

It is indeed for some things. For example, there is an operation when you
create an AudioContext that ends up sending a "statechange" event, but no
methods have been called.


>
> - There is a reference to multiple rendering threads, but I don't think
> this algorithm takes advantage of them since it always processes all nodes
> in the graph. That's fine but needs to be called out somehow until we
> define the spec in a way that supports subgraphs served by different
> threads.
>

This mostly means you can implement it with multiple threads, but it's not
very useful. I'll probably remove it for now.


>
> - It feels as though the cycle detection piece of 3.4 would be well served
> by being algorithmically described at the same level of detail as the node
> ordering. Also, I don't know if the concept of "belonging to a cycle" is
> automatically clear. What if a node is on a dead-end chain that branches
> away from a cycle, but it not directly included in the cycle's path?
>

This needs work indeed, it's just a first pass. As said, there are edge
cases.

Paul.


>
> --
> .            .       .    .  . ...Joe
>
> *Joe Berkovitz*
> President
>
> *Noteflight LLC*
> 49R Day Street / Somerville, MA 02144 / USA
> phone: +1 978 314 6271
> www.noteflight.com
> "Your music, everywhere"
>
Received on Monday, 5 October 2015 14:38:29 UTC

This archive was generated by hypermail 2.3.1 : Friday, 18 December 2015 09:00:35 UTC