Channel negotiation drops buffer swaps when several graph changes land in one render quantum
メンテナーはふだん 1 日以内に返信
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 48/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- cpp, react-native
調査の方向性
Start in common/cpp/audioapi/core/utils/graph/HostGraph.cpp, especially buildNegotiatedBufferIfNeeded, then inspect HostGraph::Node and initialization in addNode. Add the described reproductions to common/cpp/test/src/graph/GraphTest.cpp and run the graph tests; done means the batched channel changes leave the destination at the expected channel count.
索引モデルが issue の本文から書いたものです。
説明
Description
While a context is rendering, HostGraph can leave a node with the wrong channel count. Stereo
content then plays mono, and a StereoPannerNode or PannerNode placed after it no longer pans.
On a device it is intermittent: it depends on whether an audio callback runs between the JS calls.
buildNegotiatedBufferIfNeeded (common/cpp/audioapi/core/utils/graph/HostGraph.cpp) runs on the
JS thread. It skips the swap when the node's live buffer already has the computed channel count.
Swaps queued earlier in the same batch have not reached the audio thread yet. So when a node goes
2 → 1 → 2 within one batch, the second negotiation sees the live 2 and queues nothing, and the
queued swap to 1 is applied last. Offline before startRendering(), or in a suspended context, the
producer drains its own events, so the live buffer is current and the bug does not show.
A common JS pattern that should hit it (inferred from reading the code; the C++ test below is the
verified reproduction):
// In one JS task, while the context is running:
const source = ctx.createBufferSource();
source.connect(gain); // no buffer yet: 1 output channel, gain -> 1 is queued
source.buffer = stereoBuffer; // 2 output channels: gain's live buffer still has 2, nothing is queued
source.start(); // gain stays mono
Another one: a mono source and a StereoPannerNode connected to the same gain in one task. This is
what Howler's sound.stereo(pan) does: the gain stays mono and the panned output collapses to the
center.
Steps to reproduce
Add this to common/cpp/test/src/graph/GraphTest.cpp. There is no processEvents() between the two
changes, as on a running context where both apply in the same render quantum:
TEST_F(GraphTest, ComputedNumberOfChannels_MaxMode_BatchedChangesBackToLiveWidth) {
auto *mono = addChannelCountNode(*graph, {.channelCount = 1, .mode = ChannelCountMode::EXPLICIT});
auto *stereo = addChannelCountNode(*graph, {.channelCount = 2, .mode = ChannelCountMode::EXPLICIT});
auto *dest = addChannelCountNode(*graph, {.channelCount = 2, .mode = ChannelCountMode::MAX});
graph->processEvents();
ASSERT_TRUE(graph->addEdge(mono, dest).is_ok());
ASSERT_TRUE(graph->addEdge(stereo, dest).is_ok());
graph->processEvents();
EXPECT_EQ(channelsOf(dest), 2u); // fails on main: 1
}
The same happens with addEdge(mono, dest) followed by removeEdge(mono, dest) (expected 2, got
1), and with a source whose output channel number changes from 1 to 2 after addEdge, followed by
renegotiateNodeChannels (expected 2, got 1). All three fail on main (b8491e1).
Proposed fix
Record on HostGraph::Node the channel count of the last swap queued for the audio thread,
initialized in addNode (AudioGraph does not know the node yet, so reading its buffer there is
safe), and compare against it instead of the live buffer. With this change the three cases pass, and
so do the smoke suite (460 tests) and the graph category (659 tests). I can open a PR with the fix
and the tests.
Snack or a link to a repository
no React Native app. We embed the C++ engine in a custom iOS runtime; the reproduction is the GraphTest case above.
React Native Audio API version
1.0.0
React Native version
0.75.3
Platforms
iOS
JavaScript runtime
Hermes
Workflow
None
Architecture
None
Build type
None
Device
Real device
Device model
No response
Acknowledgements
Yes
- 主要言語
- C++
- スター
- 848
- フォーク
- 95
- 平均マージ
- 3日 19時間
- マージ済み PR（30日）
- 30
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
software-mansion/react-native-audio-api のほかの issue
-
android bug
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
software-mansion/react-native-audio-api#1273 · コメント 5 件 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
software-mansion/react-native-audio-api#1238 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
software-mansion/react-native-audio-api#1350 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 38/100
software-mansion/react-native-audio-api#1340 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
software-mansion/react-native-audio-api#1339 ·
メンテナーはふだん 1 日以内に返信
software-mansion/react-native-audio-api の issue をすべて見る
似ている issue
-
Mac mini M6 (16 GB): Q2_0 streaming works - measured 11.7->27.2 tok/s + arena fix for sub-32 GB Macsオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
champion good first issue remake source/qq
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
metasequoiaime/msime-windows#1025 ·
メンテナーはふだん 1 日以内に返信
-
backlog bug
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
EchoTools/nevr-runtime#653 ·
メンテナーはふだん 1 日以内に返信
-
`--fail-require-skip` never fires: run_tests.py searches stdout, but the unittest binary writes the skip summary to stderr対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
InfiniTimeOrg/InfiniTime#2492 ·