Dynamic modification of looping: (4.10.3) doesn't specify what happens when setting 'loop' to false on a playing source

[Cwiiis]

It is unspecified, it would appear, what should happen to a started, looping sound source when you set the 'loop' parameter to false.

In Firefox, this is equivalent to calling stop(0), but I would suggest that it should play the source until the end of the buffer and then stop, as there is currently no trivial way of doing this.

[cwilso]

Actually, I think that behavior is weird. The loop parameter controls whether the playback should jump back to the loopStart when loopEnd is hit, but I don't see why it should stop altogether.

Blink/Webkit will let the loop run out, and then terminate. I think this is actually good behavior; the other rational option I could see is to copy the "loop" status into the playback system at start() - effectively not allowing it to be modified after .start() is called.

I would prefer to designate the Blink/Webkit behavior, but could also see the modifications-after-start-disallowed option, which would be simpler. Note this isn't really just about 'loop' - it will have to apply to loopStart and loopEnd as well. In fact, although loopStart isn't particularly problematic, loopEnd is - if loopEnd is set to a place before the current loop position in playback, does it jump?

[karlt]

From Firefox 30, if no duration parameter has been provided, then, when 'loop'
changes to false, the buffer will continue playing until the end of the
buffer.

What the duration parameter should do is
#71

If loopEnd is set to a place before the current playback position (while
'loop' is still true), then Firefox 30, will jump to loopStart.
I'm not clear that is useful, especially while loopStart moving to after the current position has no immediate effect, but I not clear what if anything would be better.

[cwilso]

Incidentally, the spec does imply that the loop attribute is sampled when start() is called:

If the loop attribute is true when start() is called, then playback will continue indefinitely until stop() is called and the stop time is reached.
(from http://webaudio.github.io/web-audio-api/#looping-AudioBufferSourceNode)

This is not what browsers do today (see my investigation from Feb 21)

[cwilso]

The desired behavior (according to WG accord) is that if loop changed from true to false while in the loop, the playback should continue from the current position as if loop had always been false (i.e. exiting the loopEnd and continuing to play the rest of the buffer).

[Cwiiis]

So exactly the behaviour I said would be nice in the initial comment :)