Re: stability of AudioBufferSourceNode.playbackState, and activeSourceCount

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.

A more general event triggered (eventually) on active source count reaching zero for any audio node might be more useful.

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

.            .       .    .  . ...Joe

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

On Mar 19, 2013, at 12:57 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com> wrote:

> Actually let me rephrase that.  There is at least one use case to expose some kind of a "finished" event to Web content.  While talking to a few developers working on a Web Audio app, they've expressed the need to know roughly when a buffer source stream is finished playing back so that they can clean up the resources that they have associated with that source node, and delete the JS reference they're holding to that node to enable it to be destroyed and removed from the graph.  However, this use case does not need immediate notification when the sound is played back, so we can rely on an event being dispatched from the HTML5 event loop.  Given the recent change to the spec making AudioNode an EventTarget, this is really easy to add by just adding an onfinished handler to AudioBufferSourceNode (and OscillatorNode for that matter), and explicitly stating in the spec that this event does not necessarily fire as soon as the playback is finished, but at some point after it has finished.  Which is better than the current STATE_FINISHED state which needs to be polled for by Web content to make this use case work.
> 
> What do you think about this alternative?  If there is a use case for getting notified of roughly when playback starts, we can consider adding a similar event for that with similar semantics, but I can't think of such a use case off hand.
> 
> --
> Ehsan
> <http://ehsanakhgari.org/>
> 
> 
> On Mon, Mar 18, 2013 at 11:11 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com> wrote:
>> crogers, do you have any feedback regarding this?  I am fairly strongly against having playbackState change its value before the script yields execution to the main event loop, as it implies that the implementation will need to lock on the audio thread.  And without that property, playbackState as currently spec'ed is fairly useless since there will be no guarantee whether its value when queried reflects the reality (that is, if it returns PLAYING or FINISHED.)  I would like to propose that this attribute (and activeSourceCount for the exact same fundamental reason) should be removed from the spec.
>> 
>> Cheers,
>> 
>> --
>> Ehsan
>> <http://ehsanakhgari.org/>
>> 
>> 
>> On Mon, Oct 29, 2012 at 7:26 AM, Robert O'Callahan <robert@ocallahan.org> wrote:
>>> AudioBufferSourceNode.playbackState is described as being changed by the start() method (i.e. synchronously on the HTML5 event loop thread) and then being changed due to audio processing (i.e. NOT on the HTML5 event loop thread). How are changes to PLAYING_STATE and FINISHED_STATE reflected to the HTML5 event loop thread? Is it supposed to be possible for script to check playbackState one moment and see SCHEDULED_STATE, then a moment later (without returning to the event loop) to check it again and see PLAYING_STATE? I hope not, for that would make playback states other than UNSCHEDULED and SCHEDULED pretty much impossible to use correctly.
>>> 
>>> Hmm, actually, what are the use-cases for playbackState? I can't tell what it could be safely used for.
>>> 
>>> activeSourceCount has similar issues, since it counts the playing AudioBufferSourceNodes. Is it supposed to change at arbitrary times? What are the use-cases for activeSourceCount anyway?
>>> 
>>> Rob
>>> -- 
>>> Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28]
>