Fix #915 The case for sample-accurate start() #1024
Conversation
| attribute is converted to an exact sample frame offset within the | ||
| buffer by multiplying by the buffer's sample rate and rounding to | ||
| the nearest integer value. Thus its behavior is independent of | ||
| the value of the <a href= |
There was a problem hiding this comment.
This part about the behavior with respect to the playbackRate is important and should be left in, here and below.
There was a problem hiding this comment.
Let me review this again. i was under the impression that we were not quantising to the closest sample. I might have got my wires crossed with this one.
There was a problem hiding this comment.
No, you are right; not quantizing to the closest sample. But we need to still say that where loopStart and loopEnd in the AudioBuffer is independent of the playbackRate. I think people were (previously) wondering if the playbackRate affected loopStart and loopEnd. If I set them, and then set playbackRate to 2, what gets looped? This section says you'll get the original region looped twice.
There was a problem hiding this comment.
Seconding @rtoy's observation that we have to specify that the loop points (though now unquantized) are defined in terms of the buffer's sample rate, not the computed playback rate.
If loop points were evaluated in terms of computed playback rate, the behavior with a modulated playback rate would be chaotic and unpredictable.
|
This seems tricky. I'm not sure what the best way to deal with this would be. Removing the rounding to the sample frame is certainly right, but I'm not sure if we need to say anything more. Perhaps a diagram that illustrates how time and sampling interact would be appropriate. That would also help explain how time in AudioParams work too. (This is not to say you need to draw this diagram for this PR.) For the oscillator case, I think it's pretty clear. Let s(t) be the basic waveform of the oscillator. If you have osc.start(ts), and t0 <= ts < t1, where t0, and t1 are the sample points closest to ts, the output value at t0 is 0. The output value at t1, must be s(t1-ts), which is typically not 0. I think the same holds for an ABSN. You have to interpolate between the samples of the buffer. Thus, the output at time t1 is not exactly equal to the first sample of the AudioBuffer. It can be a linear interpolation between 0 and s(0), where s(n) are the samples in the AudioBuffer. Once we have this, I think it's pretty clear how loopStart and loopEnd behave. (Even if it is actually hard to describe the exact behavior.) |
| attribute is converted to an exact sample frame offset within the | ||
| buffer by multiplying by the buffer's sample rate and rounding to | ||
| the nearest integer value. Thus its behavior is independent of | ||
| the value of the <a href= |
There was a problem hiding this comment.
Seconding @rtoy's observation that we have to specify that the loop points (though now unquantized) are defined in terms of the buffer's sample rate, not the computed playback rate.
If loop points were evaluated in terms of computed playback rate, the behavior with a modulated playback rate would be chaotic and unpredictable.
|
@mdjp is this ready to merge? |
WG should we explicitly statethat this is not quantised to samples?
eg.
It is in the same time coordinate system as the AudioContext's currentTime attribute.