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

Reply via email to