Re: stability of AudioBufferSourceNode.playbackState, and activeSourceCount

On Wed, Mar 20, 2013 at 9:21 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

>
> On Tue, Mar 19, 2013 at 3:56 PM, Joseph Berkovitz <joe@noteflight.com>wrote:
>
>> We can fire an event once for each node that finishes its input (or
>> consumes its buffer in the case of AudioBufferSourceNode.)  Would that
>> address your concern?
>>
>>
>> If it 1) works for internal nodes within a graph (i.e. nodes that receive
>> input from one or more sources) and 2) fires after all upstream sources
>> become inactive without requiring the programmer to separately track the
>> state of these sources, then yes, that would address my concern. To go
>> further, I'd say it's my preferred approach.
>>
>
> Yes, more specifically, in a simple example where you have an
> AudioBufferSourceNode feeding into a GainNode feeding into an
> AudioDestinationNode, and no other nodes, a "finished" event will be
> dispatched first to the AudioBufferSourceNode, then to the GainNode, and
> then finally to the AudioDestinationNode.  If there is another node feeding
> into the AudioDestinationNode, that node will only get its "finished" event
> once that event has been dispatched to that other source as well.  Does
> that satisfy your requirements?
>

I assume you mean here that the developer has the choice to add an event
listener to any of these nodes and the event would only be dispatched in
this case?  Generally, it's only the AudioBufferSourceNode we really care
about.  The other nodes not so much.  I'd really like to avoid making this
overly complicated and I think there will be ways to handle the use cases
with a simple model.  In fact, up to this point we've lived with no
notifications at all and developers have managed to find ways to deal...



>
>
>>
>>
>>> A more general event triggered (eventually) on active source count
>>> reaching zero for any audio node might be more useful.
>>>
>>
>> If we send a finished event once per node, this can be implemented in the
>> script by just having a counter, right?
>>
>>
>> If a "finished" event is fired for internal nodes like mixers, filters,
>> etc, is there a need for a counter? The dispatch of the event would imply
>> that all sources upstream of the target node are now inactive. So to clean
>> up an entire subgraph (which is an important use case) one simply attaches
>> a listener to the output node of that subgraph (which presumably feeds into
>> some higher-level destination that doesn't get cleaned up).
>>
>
> Yes, that's true.  A counter is only needed for the case where you might
> attach more nodes in the future to the input of the same node, for example,
> in the case of the destination node.  But really that depends on the use
> case.  The point is that with the finished event, you don't _need_
> activeSourceCount in the Web Audio implementation, if you do need it, you
> can implement it in Javascript.
>
>
>> I think the counter idea gets messy if you have subgraphs that are more
>> complex than simple assemblies of buffer sources.
>>
>
> Yes.  I actually can't think of a good use case to have the counter
> myself.  :-)
>
>
>>
>> For starters what if the spec is just loosened so that the change in
>>> state is not guaranteed to be immediate? Lets also think separately about
>>> how events might assist on graph cleanup...
>>>
>>
>> Well, making the state updates not immediate addresses the performance
>> concern that I have, but I still think that this is a useless attribute to
>> support, but if crogers doesn't want to remove it because of backwards
>> compatibility concerns, then this is the least we should do to make this
>> efficiently implementable.
>>
>>
>> Sounds like Chris is OK with removing it -- I was just looking for the
>> minimal change that would address the problem you identified but I don't
>> mind if it becomes deprecated.
>>
>
> Great!
>
> --
> Ehsan
> <http://ehsanakhgari.org/>
>
>