Re: stability of AudioBufferSourceNode.playbackState, and activeSourceCount

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