duration parameter to AudioBufferSourceNode.start is handled incorrectly

[brianchirls]

Per the spec:

The duration parameter describes the duration of the sound (in seconds) to be played. If this parameter is passed, this method has exactly the same effect as the invocation of start(when, offset) followed by stop(when + duration).

None of the major browsers implement it this way. If the playbackRate is set to anything other than 1, actual duration of the sound emitted is the value of the argument divided by playbackRate. The duration applies to the length of the source sample before it is adjusted by the playbackRate. This is not the same as using start without a duration followed by stop, as described. The latter will play the sped up or slowed down clip for the correct duration.

Here is a link to a simplified test case:
https://codepen.io/brianchirls/pen/zaKgva?editors=1111

The above applies to recent versions of Firefox, Chrome, Safari and Edge. I don't really mind whether the spec gets changed or the browsers change behavior as long as it's consistent. I figured I'd file here first for discussion rather than try to chase down four browser vendors.

[brianchirls]

Incidentally, I suspect based on some informal experimenting that linearRampToValueAtTime and other scheduling messages on AudioParams behave similarly, where the end time is in the buffer's time system.

The spec clearly states that the endTime parameter should be the "time in the same time coordinate system as the AudioContext's currentTime attribute at which the automation ends." This is likely wrong as well.

[brianchirls]

Here's a test case for linearRampToValueAtTime.

This is an audio clip at playbackRate = 0.25. First click play, then click fade out. It should take 1 second to fade out, but (in Chrome) it clearly takes longer. In Firefox and Safari it just...sounds bad.
https://codepen.io/brianchirls/pen/bKBbJz?editors=0011

[rtoy]

I think these are bugs in the implementation, but I need to examine https://webaudio.github.io/web-audio-api/#playback-AudioBufferSourceNode in detail.

For https://codepen.io/brianchirls/pen/bKBbJz?editors=0011, I think there's a bug in the example. The button says 1 sec but the code says the ramp ends in 2 sec. Plus the ramp is on the gain node and is independent of the buffer source, so I'd be really surprised if these interacted in any way.

Firefox (nightly) abruptly stops. I think this is due to two possible reasons: the value setter is supposed to be identical to setValueAtTime. But barring that, linearRampToValue without a preceeding event is supposed to implicitly insert a setValueAtTime at the time of the call to establish a starting event for the ramp. If this is the case, these are bugs in Firefox and you should files bugs there.

[rtoy]

A quick read of https://webaudio.github.io/web-audio-api/#playback-AudioBufferSourceNode indicates that duration is independent of the playback rate. See line 92 of the algorithm.

[brianchirls]

@rtoy Yes, you're right about the bugs in my example. Thanks for taking a close look at that. I have fixed those. It plays better in Firefox now, though there is still a little click at the end. And it does sound like closer to a 1 second delay. So hopefully this one is not an issue.

Also, yes, I think you are probably correct that this is a bug in the implementation. Indeed, I see in the same algorithm that the buffering takes playback rate into account as well. However, it could take a very long time to get all the browser vendors to fix this. I saw there are already a few bug tickets for playbackRate that go unaddressed for months and years. They're not going to fix it at the same time, if ever, and writing workarounds for varying implementations is going to be a nightmare.

If there is consensus here that the spec is fine as is and that this should be addressed in the browsers, I'm happy to file bug tickets with those browser vendors that accept them. I hope others will chime in where appropriate.

[rtoy]

The algorithm is relatively new (about a 1-1/2 years old). Chrome already has https://crbug.com/712256, but clearly nothing has been done yet. But now that you've raised the issue here, the priority of that bug may change.

[karlt]

Before 662e494 duration was "the duration of the portion (in seconds) to be played. If this parameter is not passed, the duration will be equal to the total duration of the AudioBuffer minus the offset parameter."

It seems the intention was that duration specified a portion of the buffer, not a duration of playback. The implementation behavior reported here is consistent with that understanding. duration was also consistent with offset.

That changeset was intended to define the effect of duration when looping for #421

The breaking change for non-looping behavior was not explicitly called out, and so I don't know whether that was intentional.

[rtoy]

Yeah, that effect for non-looping is probably an oversight. I think the current behavior is much easier to understand.

I think getting the old behavior is fairly straightforward if somewhat wasteful: Create a new AudioBuffer from the original that contains just the samples you want. Apply that to a new AudioBufferSourceNode and start(when, offset) with the desired playbackRate. This will play out everything in the buffer, adjusted for the playbackRate.

We could possibly also adjust the algorithm to allow playbackRate to affect duration, but seems pretty hard; it took quite a while to hash out all the corner cases in the current algorithm.

[brianchirls]

@rtoy Yes, I saw that issue at crbug and the fact that it went untouched for a year is why I'm not so optimistic.

It sounds like you're all on top if it, so I'll let you sort it out. Please let me know if I can be of any further assistance. Thanks.

[rtoy]

Today's teleconf:

We should try to preserve the existing meaning of duration for non-looping sources and try to update the algorithm to apply for looping sources too. Needs investigation on whether it can be defined.

[rtoy]

@joeberkovitz suggested we can change the algorithm to preserve existing behavior and still have a meaningful interpretation for looping.