search

WebAudio / web-audio-api

The Web Audio API v1.0, developed by the W3C Audio WG
https://webaudio.github.io/web-audio-api/
Other
1.06k stars 168 forks source link

The .stop function of AudioBufferSourceNode is poorly defined. #15

Closed olivierthereaux closed 10 years ago

olivierthereaux commented 11 years ago

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 commented 11 years ago

+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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

cwilso commented 10 years ago

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/WebAudio/web-audio-api/issues/15#issuecomment-32972148 .

padenot commented 10 years ago

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