[BUG] WebRtcApmModifier: AEC silently does nothing - far-end (reverse) stream is never fed to APM
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 52/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 静か
- 技術スタック
- csharp
調査の方向性
まず、FullDuplexDevice.OnAudioProcessed を通じた WebRtcApmModifier の HandleAudioEngineProcessedForAec の登録を追跡し、次に再生デバイスの MasterMixer と ProcessReverseStream パスを調べます。完了とは、APM がレンダリング/再生信号を reverse stream として受け取り、近端処理を維持したまま AEC がキャプチャされたエコーをキャンセルすることです。
索引モデルが issue の本文から書いたものです。
説明
Requirements
- I have searched the existing issues to ensure this bug has not already been reported.
- I have provided a clear and concise description of the bug.
- I have provided detailed steps to reproduce the bug.
- I have included a minimal reproducible example (MRE) if applicable.
- I have provided error messages and stack traces if applicable.
- I have completed the environment information.
1. Describe the Bug
Summary
When using WebRtcApmModifier with AEC enabled on a FullDuplexDevice, the acoustic echo canceller never receives a far-end reference signal, so ProcessReverseStream is effectively never called and echo cancellation does nothing. Noise suppression (NS) and the high-pass filter still work on the near-end capture stream, which makes the audio sound processed and hides the fact that AEC is a no-op.
Root cause
WebRtcApmModifier wires its internal far-end handler (HandleAudioEngineProcessedForAec, which only acts on Capability.Playback frames) to the FullDuplexDevice/engine OnAudioProcessed event. However, that event is raised only for the capture device path — playback/render devices never raise OnAudioProcessed. As a result the handler is only ever called with capture (near-end) frames, which it ignores, and it is never called with the playback (far-end) frames it actually needs. The reverse stream therefore stays empty and AEC has no reference signal.
Suggested fix
The modifier needs to actually receive the render/playback post-mix as the far-end signal. Either:
- raise the processed-audio event on playback/render devices as well (so the existing
Capability.Playbackhandler gets fed), or - inside
WebRtcApmModifier, explicitly driveProcessReverseStreamfrom the playback device's master mixer instead of relying on the capture-onlyOnAudioProcessedevent.
2. Steps to Reproduce
- Create a
FullDuplexDeviceand attachWebRtcApmModifierwithaecEnabled: true(NS/HPF on or off — doesn't matter). - Play back a signal on the playback device while capturing on the mic in a shared acoustic path (speakers audible to the mic).
- Observe that captured audio still contains the full echo of the playback signal — AEC has no effect. Instrumenting
ProcessReverseStreamshows it is never called with real render data.
3. Expected Behavior
With aecEnabled: true, the APM's reverse stream should be continuously fed with the render/playback signal (what is being sent to the speakers), so AEC3 can build its reference and cancel echo from the capture stream.
4. Current Behavior
The far-end handler is registered but never invoked with playback audio, so ProcessReverseStream is never driven. AEC produces no cancellation; the caller hears their own echo. Because NS/HPF still run on the near-end, there is no error and the output is not obviously broken — the failure is silent.
5. Minimal Reproducible Example (MRE)
6. Error Messages and Stack Trace (if applicable)
SoundFlow Version
1.4.0
.NET Version
.NET 10.0
Operating System
Windows 11
Architecture
x64
Audio Backend Used (if known)
Full-duplex WASAPI device
Specific Audio Hardware (if relevant)
No response
8. Affected Components/Modules (if known)
SoundFlow.Extensions.WebRtc.Apm 1.4.0
9. Impact
No response
10. Possible Workaround (if known)
I route the playback master-mix into the modifier's private far-end handler ourselves via a small SoundModifier attached to PlaybackDevice.MasterMixer, invoking the internal HandleAudioEngineProcessedForAec with Capability.Playback (currently via reflection, since the method is non-public). The buffer is passed through unmodified. With this in place AEC converges and cancels correctly.
11. Additional Context
No response
- 主要言語
- C#
- スター
- 512
- フォーク
- 56
- PR マージ指標
- 30日以内にマージされた PR はありません
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
LSXPrime/SoundFlow のほかの issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
-
enhancement
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
-
question
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
-
bug
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
LSXPrime/SoundFlow の issue をすべて見る
似ている issue
-
effort:S P3 refactor
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
nightscout/nocturne#1532 ·
-
core dependencies
難易度 1/5 1時間未満 初心者へのやさしさ 80/100
-
documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
C#/.NET Roslyn LSP オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
DotNetNext/SqlSugar#1458 ·