-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dynamic modification of looping: (4.10.3) doesn't specify what happens when setting 'loop' to false on a playing source #281
Comments
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? |
From Firefox 30, if no duration parameter has been provided, then, when 'loop' What the duration parameter should do is If loopEnd is set to a place before the current playback position (while |
Incidentally, the spec does imply that the loop attribute is sampled when start() is called:
This is not what browsers do today (see my investigation from Feb 21) |
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). |
So exactly the behaviour I said would be nice in the initial comment :) |
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.
The text was updated successfully, but these errors were encountered: