W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

Re: stability of AudioBufferSourceNode.playbackState, and activeSourceCount

From: Marcus Geelnard <mage@opera.com>
Date: Tue, 30 Oct 2012 10:06:14 +0100
To: public-audio@w3.org, "Robert O'Callahan" <robert@ocallahan.org>
Message-ID: <op.wmzh8oq1m77heq@mage-speeddemon>
Also see: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17343


Den 2012-10-29 12:26:32 skrev Robert O'Callahan <robert@ocallahan.org>:

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

Marcus Geelnard
Core graphics developer
Opera Software ASA
Received on Tuesday, 30 October 2012 09:06:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:14 UTC