You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The offset parameter supplies a playhead position where playback will begin. If 0 is passed in for this value, then playback will start from the beginning of the buffer. A RangeError exception MUST be thrown if offset is negative. If offset is greater than loopEnd, playback will begin at loopEnd (and immediately loop to loopStart). offset is silently clamped to [0, duration], when startTime is reached, where duration is the value of the duration attribute of the AudioBuffer set to the buffer attribute of this AudioBufferSourceNode.
There are a number of issues and questions here, all answered by the algorithm:
This is true only when playbackRate is > 0. If no, then it will go backward in the loop. The normative algorithm says yes, only when looping is enabled. This could be fixed by changing the prose.
Does this need to happen only when looping is enabled? The algorithm, which is normative says says yes. This is fine, but we need to change the prose.
Does the opposite happen when playbackRate is < 0, meaning the offset should be clamped in [loopStart, loopEnd] ? The normative algorithm says no. This seems inconsistent, but is the current normative requirement.
In this case, is it allowed to start after the looped region, and then enter the looped region like it is for the positive playbackRate case? The normative algorithm says no. his seems inconsistent, but is the current normative requirement.
Examples:
Normal case
With a buffer of 3.0 seconds: starting, say, at 0.0, with a playbackRate of 1.0, and end/start loop points of respectively 1.0 and 2.0, will play [0.0, 1.0], then looping continuously in [1.0, 2.0].
Backward case
With a buffer of 3.0 second: starting, say, at 3.0, with a playbackRate of -1.0, and end/start loop points of respectively 1.0 and 2.0, will play [2.0, 3.0] backwards, then looping continuously (also backwards) in [1.0, 2.0].
The text was updated successfully, but these errors were encountered:
The spec is weird (emphasis mine):
There are a number of issues and questions here, all answered by the algorithm:
playbackRate
is > 0. If no, then it will go backward in the loop. The normative algorithm says yes, only when looping is enabled. This could be fixed by changing the prose.playbackRate
is < 0, meaning the offset should be clamped in[loopStart, loopEnd]
? The normative algorithm says no. This seems inconsistent, but is the current normative requirement.playbackRate
case? The normative algorithm says no. his seems inconsistent, but is the current normative requirement.Examples:
Normal case
With a buffer of
3.0
seconds: starting, say, at0.0
, with aplaybackRate
of1.0
, and end/start loop points of respectively1.0
and2.0
, will play[0.0, 1.0]
, then looping continuously in[1.0, 2.0]
.Backward case
With a buffer of
3.0
second: starting, say, at3.0
, with aplaybackRate
of-1.0
, and end/start loop points of respectively1.0
and2.0
, will play[2.0, 3.0]
backwards, then looping continuously (also backwards) in[1.0, 2.0]
.The text was updated successfully, but these errors were encountered: