Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 268a25f376b16d07e316f099693025f2b61615cc
https://github.com/WebKit/WebKit/commit/268a25f376b16d07e316f099693025f2b61615cc
Author: Chris Dumez <[email protected]>
Date: 2026-08-25 (Tue, 25 Aug 2026)
Changed paths:
M
LayoutTests/imported/w3c/web-platform-tests/webaudio/the-audio-api/the-audiobuffersourcenode-interface/audiobuffersource-playbackrate-negative-expected.txt
M Source/WebCore/Modules/webaudio/AudioBufferSourceNode.cpp
Log Message:
-----------
AudioBufferSourceNode renders only silence for an out-of-bounds start()
offset with a negative playbackRate
https://bugs.webkit.org/show_bug.cgi?id=322373
Reviewed by Jean-Yves Avenard.
start() silently clamps offset to [0, duration], so a negative playbackRate can
leave the playhead exactly at the end of the buffer. renderFromBuffer() decided
once per render quantum whether the playhead was usable and returned false when
it was not, making process() zero the whole bus. But only the first frame is
outside the buffer: the playhead immediately descends back into it. A 4-frame
buffer started at offset == duration with rate -1 therefore rendered four silent
frames instead of one silent frame followed by 4, 3, 2.
This aligns us with the spec, which makes that decision per frame rather than
per quantum:
```
if (bufferTime >= 0 && bufferTime < buffer.duration)
output.push(playbackSignal(bufferTime));
else
output.push(0); // past end of buffer, so output silent frame
```
Unlike bugs 320870 and 322372, no spec ambiguity is involved: the existing text
already specifies this, and we simply did not implement it.
It also aligns us with Blink, whose "Reverse Out-Of-Bounds Playhead Catch-up"
loop in AudioBufferSourceHandler::RenderFromBuffer() is equivalent, added for
the
same reason.
Forward playback is unaffected. With a positive rate the playhead only moves
further past the end of the buffer, so bailing out and rendering silence was
already the correct result and still is.
*
LayoutTests/imported/w3c/web-platform-tests/webaudio/the-audio-api/the-audiobuffersourcenode-interface/audiobuffersource-playbackrate-negative-expected.txt:
Rebaselined: "handles offset exactly at duration with negative rate" and
"handles out-of-bounds start offset correctly" now pass. The one remaining
failure is a negative loopStart, addressed separately in bug 322372.
* Source/WebCore/Modules/webaudio/AudioBufferSourceNode.cpp:
(WebCore::AudioBufferSourceNode::renderFromBuffer):
Canonical link: https://commits.webkit.org/319779@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications