[BUG] WebRtcApmModifier: AEC silently does nothing - far-end (reverse) stream is never fed to APM
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 52/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 冷清
- 技术栈
- csharp
调研方向
首先跟踪 WebRtcApmModifier 的 HandleAudioEngineProcessedForAec 通过 FullDuplexDevice.OnAudioProcessed 进行注册的过程，然后检查播放设备的 MasterMixer 和 ProcessReverseStream 路径。完成的标准是 APM 将渲染/播放信号作为其反向流接收，并且 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#
- 星标
- 520
- 派生
- 56
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 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 一周以上 新手友好度 30/100
-
bug
难度 4/5 3-5 天 新手友好度 45/100
查看 LSXPrime/SoundFlow 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 7 天内回复
-
难度 1/5 1 小时以内 新手友好度 65/100
vchelaru/FlatRedBall2#1481 ·
维护者通常 1 天内回复
-
ai-chat bug trivial
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
area-signalr
难度 2/5 1-3 小时 新手友好度 75/100
dotnet/aspnetcore#69842 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复