Re: stability of AudioBufferSourceNode.playbackState, and activeSourceCount

On Tue, Mar 19, 2013 at 7:46 AM, Joe Berkovitz <joe@noteflight.com> wrote:

> FYI I also have not found the state useful for cleanup and currently rely
> on polling and comparison of context time vs known node lifetime to remove
> resources.
>
> Not sure if this event proposal is the right way to go though if it is
> scoped to source nodes such as AudioBufferSourceNode and OscillatorNode. My
> experience is that cleanup often needs to be applied to a downstream node
> that has several sources feeding into it (I.e. the output of a subgraph) in
> which case cleanup events at the level of individual sources are messy to
> handle: they occur too far upstream from where they are needed.
>

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?


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


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

Cheers,
Ehsan