Re: stability of AudioBufferSourceNode.playbackState, and activeSourceCount

On Wed, Mar 20, 2013 at 1:22 PM, Chris Rogers <crogers@google.com> wrote:

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

I personally would be happy for now if we only add it to
AudioBufferSourceNode.  Joe wants it on all nodes, and I think we can do
that, but for the original use case that I mentioned, having the finished
event on AudioBufferSourceNode would be enough.  I will let Joe to argue
the case for the rest of the node types.

The good thing is that if in the future we decide to move the onfinished
attribute to AudioNode, we can maintain backwards compatibility with
AudioBufferSourceNode.

--
Ehsan
<http://ehsanakhgari.org/>