Re: stability of AudioBufferSourceNode.playbackState, and activeSourceCount

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