Re: stability of AudioBufferSourceNode.playbackState, and activeSourceCount

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?


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