Re: stability of AudioBufferSourceNode.playbackState, and activeSourceCount

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.

.            .       .    .  . ...Joe

Joe Berkovitz
President

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"