The .stop function of AudioBufferSourceNode is poorly defined.

[olivierthereaux]

Originally reported on W3C Bugzilla ISSUE-20229 Tue, 04 Dec 2012 08:46:43 GMT
Reported by Li Yin
Assigned to

From the spec, it says "stop must only be called one time and only after a call to start or stop, or an exception will be thrown."

It's confused to me that if stop can be called only one time, it should be impossible that stop can be called after stop. In offlinemode, stop can be called multiple times from web developers' eyes.

So maybe it will be more reasonable if we describe it like this:
start can be called only when playbackState is UNSCHEDULED_STATE, or InvalidStateError exception will be thrown.
stop can be called only when playbackState is SCHEDULED_STATE or PLAYING_STATE, if not, InvalidStateError exception will be thrown.

[bjornm]

+1 on the playbackState descriptions, the current spec seems to tight for my scenario for a sampler playback:

1. I click play on the transport.
2. A bunch of AudioBufferSourceNodes are scheduled to play the first notes in the composition. They receive calls to start() and stop() in advance and will start and stop accordingly.
3. I press stop on the transport before the composition has ended. I would now like to call stop(0) on all AudioBufferSourceNodes, both scheduled and playing.

This would mean setting an earlier stop time for nodes currently playing. The current spec won't allow me to do this but the change above would.

...or maybe there is another option I haven't thought of? Any insight appreciated.

[cwilso]

Discussion results: last-called stop() should take effect, i.e. an overwrite of the last stop(). Multiple stop() invokes should not throw, even if the playback has already stopped.

[Theodeus]

That sounds great, Chris. Does "discussion results" mean that the change is making its way into the spec anytime soon?

The exceptions has started being thrown in the latest (stable) version of Chrome which has broken quite a few sites, among others jamwithchrome.com, which rely on being able to call stop() multiple times, as described by bjornm, to get the interactive elements of the site to work. I'd assume the spec needs to be updated for this to be fixed in the implementations?

[Theodeus]

Clarification:

"which has broken quite a few sites" - as in I think this is a common use case that should be supported, and it's currently really hard/impossible to work around it.

[cwilso]

Yes, "discussion results" meant we discussed it in the WG call last week, agreed multiple stop() invokes should not throw, and it will make its way into the spec this way. Oh, and we've got a fix for Chrome in the pipeline.

[padenot]

cwilso, have we decided who will edit the spec ? I'll go and write the patch for Gecko anyways.

[cwilso]

I grabbed it but you're welcome to reassign it if you'd rather.

On Tue, Jan 21, 2014 at 2:36 PM, Paul ADENOT notifications@github.comwrote:

cwilso, have we decided who will edit the spec ? I'll go and write the
patch for Gecko anyways.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/15#issuecomment-32972148
.

[padenot]

Nope, I'll let you the pleasure to write the spec patch :-)