Re: stability of AudioBufferSourceNode.playbackState, and activeSourceCount

OK, great!  Do you want me to write up the changes to the spec and submit
them in a bug/here?

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


On Tue, Mar 19, 2013 at 2:56 PM, Chris Rogers <crogers@google.com> wrote:

>
>
>
> On Mon, Mar 18, 2013 at 8: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/>
>>
>
>  I think it should be possible to remove .playbackState as publicly
> exposed to JS.  We can still describe the internal states for
> implementors...
>
> .activeSourceCount can probably also go away if we implement some kind of
> event listener when playing is finished.
>
> Chris
>
>
>
>
>>
>>
>> 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]
>>>
>>>
>>
>