Re: stability of AudioBufferSourceNode.playbackState, and activeSourceCount

Yes, I understand (and employ) GainNodes in exactly this way. But it would still be useful to know when an internal node has become inactive because it has no active sources and surely the implementation knows this. Perhaps the event is not named correctly -- "finished" may be over specific. "Quiescent" might be the concept that applies here. For a source node these amount to the same thing.

.            .       .    .  . ...Joe

Joe Berkovitz
President
Noteflight LLC
+1 978 314 6271
www.noteflight.com
"Your music, everywhere."

On Mar 20, 2013, at 6:41 PM, Chris Rogers <crogers@google.com> wrote:

> 
> 
> 
> On Wed, Mar 20, 2013 at 2:41 PM, Joseph Berkovitz <joe@noteflight.com> wrote:
>> 
>> On Mar 20, 2013, at 5:28 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com> wrote:
>>>>> 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.
>> 
>> I am not advocating for immediately introducing this event into the spec. In fact, I am one of those who is currently "living with no notifications at all" as Chris said.
>> 
>> However, if we are actually going to now figure this event out and spec it, I think we should make the event worthwhile in terms of developer value and not just proceed by increments. I disagree that AudioSourceBufferNode is the only node type that developers would really care about.  Subgraphs are the typical "unit of work" in creating/destroying audio generators, not individual source nodes. 
>> 
>> Presumably any Web Audio API implementation has some idea of when any node, whether an internal or a source node, has become inactive. Why is it overly complicated to expose this basic internal knowledge to a developer who can make use of it?  The Web Audio API already takes care of a lot of housekeeping in a really nice way and this seems like a simple extension of that housekeeping.
> 
> One important difference between the scheduled nodes like AudioBufferSourceNode and OscillatorNode versus the other nodes is that for the scheduled nodes there is a specific time when the node is finished.  This is not true of a GainNode (or most of the other effect nodes) which is not finished just because some specific source connected to it has finished.  At any time in the future another source node may be connected to a GainNode and a new sound will be started.  In fact, at any given time there are often multiple sources connected to GainNodes.  Each of these sources is starting and stopping with potentially overlapping times.
>  
>> 
>> .            .       .    .  . ...Joe
>> 
>> Joe Berkovitz
>> President
>> 
>> Noteflight LLC
>> Boston, Mass.
>> phone: +1 978 314 6271
>> www.noteflight.com
>> "Your music, everywhere"
>