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

stability of AudioBufferSourceNode.playbackState, and activeSourceCount

From: Robert O'Callahan <robert@ocallahan.org>
Date: Tue, 30 Oct 2012 00:26:32 +1300
Message-ID: <CAOp6jLZbMyJUUwO7VwRRa55duZYVXWBLF1e2RMjdbAJZ5WVMvg@mail.gmail.com>
To: public-audio@w3.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?

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]
Received on Monday, 29 October 2012 11:27:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:03 UTC