Re: stability of AudioBufferSourceNode.playbackState, and activeSourceCount

On Fri, Mar 22, 2013 at 5:11 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

> On Thu, Mar 21, 2013 at 4:15 PM, Joseph Berkovitz <joe@noteflight.com>wrote:
>
>>
>> On Mar 21, 2013, at 12:20 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com>
>> wrote:
>>
>>
>> On Wed, Mar 20, 2013 at 7:18 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>>
>>> Indeed, automatically firing "finished" on a GainNode doesn't make
>>> sense, because if even all other JS references have been dropped the event
>>> handler could always "resurrect" the node by retrieving the node via
>>> event.target and adding a new input to it, and then the node isn't finished.
>>>
>>
>> Good point, my mistake.
>>
>>
>>> A separate "quiescent" event woiuld make some sense, but would have to
>>> be carefully defined.
>>>
>>
>> OK, how about we stick to introducing the finished event for
>> AudioBufferSourceNode and OscilatorNode for now and eliminate
>> playbackState?  We can continue discussing the "quiescent" event but I
>> don't think that we need to hold the finished event for that, because it
>> turns out that it will not be the proper solution for that case.
>>
>>
>> That seems fine -- and I agree that a tool for detecting the
>> "finishedness" of an audio buffer or oscillator node is a useful thing.
>>
>
> Great!  crogers, do you want me to write up a spec change for this?
>

Sure sounds good, can we start by just removing the . playbackState and
work on the event(s) later?


>
> --
> Ehsan
> <http://ehsanakhgari.org/>
>

Received on Saturday, 23 March 2013 00:16:10 UTC