Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: d812eb91c045cbc32b619fecd38eac3b732a6d20
https://github.com/WebKit/WebKit/commit/d812eb91c045cbc32b619fecd38eac3b732a6d20
Author: Ahmad Saleem <[email protected]>
Date: 2026-07-26 (Sun, 26 Jul 2026)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/webaudio/the-audio-api/the-audiobuffersourcenode-interface/audiobuffersource-output-channel-count-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/webaudio/the-audio-api/the-audiobuffersourcenode-interface/audiobuffersource-output-channel-count.html
M Source/WebCore/Modules/webaudio/AudioBufferSourceNode.cpp
M Source/WebCore/Modules/webaudio/AudioBufferSourceNode.h
Log Message:
-----------
AudioBufferSourceNode output channel count ignores actively-processing state
https://bugs.webkit.org/show_bug.cgi?id=320309
rdar://183245229
Reviewed by Chris Dumez.
Per the Web Audio API, an AudioScheduledSourceNode is actively processing
"if and only if it is playing for at least part of the current rendering
quantum", and "AudioNodes that are not actively processing output a single
channel of silence" [1]. The number of channels of an AudioBufferSourceNode's
output therefore equals the number of channels of its buffer only while the
node is playing, and "is one channel of silence if buffer is null" [2].
We instead latched the output channel count in the buffer setter, from the
buffer alone, so it was wrong in three cases:
- A node with a buffer that was never started kept the buffer's channel
count, though it is not actively processing.
- Setting buffer back to null left the previous count in place.
- A playing node whose buffer is null kept the previous count.
The end-of-playback case already collapsed to a single channel, but only
incidentally: finish() drops the context's reference to the node, which
disables its outputs, which removes them from
AudioSummingJunction::maximumNumberOfChannels(). Nothing consulted playback
state, so the cases above were unaffected by that path.
Compute the count from both the buffer and the playback state instead, in a
new updateOutputChannelCount(), and call it from the buffer setter and from
startPlaying() once the node is scheduled. Setting the buffer to null now
also clears the stale source and destination channel spans.
startPlaying() now takes the graph lock, since changing the output channel
count reconfigures the graph. It is acquired after the process lock, matching
the order used by process() and setBufferForBindings() to avoid deadlock.
Firefox already behaves as specified in all of these cases; Chrome shares the
old behavior.
[1] https://webaudio.github.io/web-audio-api/#AudioNode-actively-processing
[2] https://webaudio.github.io/web-audio-api/#AudioBufferSourceNode
Test:
imported/w3c/web-platform-tests/webaudio/the-audio-api/the-audiobuffersourcenode-interface/audiobuffersource-output-channel-count.html
*
LayoutTests/imported/w3c/web-platform-tests/webaudio/the-audio-api/the-audiobuffersourcenode-interface/audiobuffersource-output-channel-count-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/webaudio/the-audio-api/the-audiobuffersourcenode-interface/audiobuffersource-output-channel-count.html:
Added.
* Source/WebCore/Modules/webaudio/AudioBufferSourceNode.cpp:
(WebCore::AudioBufferSourceNode::setBufferForBindings):
(WebCore::AudioBufferSourceNode::updateOutputChannelCount):
(WebCore::AudioBufferSourceNode::startPlaying):
* Source/WebCore/Modules/webaudio/AudioBufferSourceNode.h:
Canonical link: https://commits.webkit.org/317956@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
