Re: Errors when stopping a disconnected source node?

Raymond Toy writes:

> Let's say you've created an AudioBufferSourceNode, s, and it is not
> connected.
>
> Case 1: You call s.start(). A short time later you call s.start() again.
> Case 2: You call s.start(). Then s.stop() and s.stop() again.
>
> In case 1, is an InvalidStateError thrown because you can only call start
> once? In case 2, is an InvalidStateError thrown too since you can only call
> stop once, after a source has started?

That's right.

"start may only be called one time and must be called before stop
 is called or an exception will be thrown."

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

> In both cases, the source hasn't really "started" because it's not
> connected to anything.

One thing that helps in the interpretation of the start and stop
times is in the description of currentTime on AudioContext:

  'This is a time in seconds which starts at zero when the context
   is created and increases in real-time. All scheduled times are
   relative to it. This is not a "transport" time which can be
   started, paused, and re-positioned. It is always moving
   forward.'

The |when| parameter of the stop() method "describes at what time
(in seconds) the sound should stop playing".  So if you call
s.stop(tstop), and connect when currentTime > tstop, the sound
will not be heard.

You've seen the discussion about whether nodes play while
disconnected.

The |when| parameter of start() "describes at what time (in
seconds) the sound should start playing. It is in the same time
coordinate system as AudioContext.currentTime. If 0 is passed in
for this value or if the value is less than currentTime, then the
sound will start playing immediately."

The spec doesn't say that the output connection state of the node
affects the start time, and so in Gecko it doesn't.  Gecko starts
processing of the buffer at |when| if its audio thread is not yet
at |when| and close to "immediately" otherwise.

> I think errors should be thrown in both cases.

I agree.

Received on Wednesday, 9 October 2013 22:56:58 UTC