博客
为什么会议加上同传后容易有回声？ParleyVoice 的采集端回声消除设计
原本开会时声音很正常，接入实时同传后，却开始出现奇怪的现象：对方听到了重复的话，刚播放出来的译音又被识别了一遍，有时双方同时说话，声音还会忽大忽小。
会议软件明明已经有回声消除，为什么多加一个同传软件，问题就出现了？
关键在于：同传改变了声音的来源和去向。音频处理需要重新知道，哪些声音是人在说，哪些声音是设备刚刚播放出来的。
一、回声消除到底在消除什么？
假设对方在会议里说了一句话，这句话从你的电脑扬声器里播放出来，又被旁边的麦克风收了进去，随后传回对方。
对方就会听到一个稍晚到达的“自己”。
这就是典型的声学回声：播放出来的声音，经过空气、桌面和房间的反射，再次进入麦克风。[1]
回声消除，通常称为 AEC，英文全称是 Acoustic Echo Cancellation。它的任务，是从麦克风采集的声音里估计并抑制这部分播放回声，尽量保留本地说话人的声音。
这里有一个非常重要的条件：系统需要知道设备刚才播放了什么。
麦克风收到的声音，可能同时包含你说的话、扬声器传回来的声音和环境噪声。如果音频处理同时拿到一份播放信号，就可以把它作为参考，寻找麦克风中与这段播放相关的回声。采集信号与播放参考，是这类处理的两个关键输入。[2][3]
二、为什么会议软件原来的回声消除可能不够用了？
在普通会议里，软件通常能够掌握自己接收、播放和采集的声音。接入同传后，这个关系会复杂得多。
新增的译音，可能不在原来的播放参考里
例如，对方说的是英文，会议软件接收到的也是英文；同传软件生成并播放的，却是一段新的中文语音。
这两段声音表达的意思相近，实际波形、时长和播放时间却完全不同。
如果会议软件的回声消除只拿到了英文原声作为参考，而你的麦克风又收进了外放的中文译音，它就缺少了处理这段新增回声所需要的参考信息。
是否出现这个问题，取决于会议软件、系统音频处理以及输出设备的具体组合。新增译音由另一个应用播放时，原有处理路径可能无法完整覆盖它。
同传软件可能先于会议软件采集麦克风
双向同传还会改变输入顺序：你的声音先进入同传软件，翻译完成后，再通过虚拟麦克风送进会议。
如果同传软件最先采集到的声音里已经混有外放译音，这段回声就可能提前进入翻译模型。等到会议软件收到翻译后的声音时，输入内容已经发生了变化。
所以，在这条路径中，回声需要尽量在进入模型之前处理，才能减少重复识别和重复翻译。
声音还可能沿着错误的线路重新绕回来
另一类问题发生在数字音频路由中：应用播放的译音，又被系统声音采集收进来；或者同一条虚拟音频线路同时承担输入与输出，让声音重新回到翻译入口。
这种回授没有经过空气。处理它，需要把采集范围、输入输出方向和播放用途分清楚。
因此，接入同传后出现回声，并不意味着会议软件一定失效。更常见的原因是，新增的声音路径超出了原先的处理范围。这个判断来自对采集与播放参考机制、以及同传接线方式的分析。[2][3]
三、我们的设计：在采集时，同时引入播放参考
针对这些问题，ParleyVoice 的回声消除设计，把处理前移到了音频采集阶段。[4]
核心思路很直接：
采集麦克风声音时，把实际播放的声音也作为独立参考送入回声消除处理，在进入翻译模型之前，尽量抑制重新被麦克风收进来的播放回声。
这两路输入承担不同的职责：
| 输入 | 在回声消除中的作用 |
|---|---|
| 麦克风采集的声音 | 待处理的信号，其中可能包含本地说话、播放回声和环境噪声 |
| 实际播放的声音 | 独立的参考信号，帮助处理过程判断哪些成分来自扬声器 |
“同时输入”指的是为处理过程提供这两路信息。播放参考保持独立，用于估计回声；处理后的麦克风语音才进入后续翻译流程。
参考要贴近真正播放出来的声音
模型返回了什么音频，与扬声器最终播出了什么，并不总是完全一致。
用户可能调低音量、关闭自己的译声耳返，也可能同时播放对方的译音和自己的监听声音。参考信号需要尽量对应最终播放内容，以及实际的音量和时间关系。[4]
如果某个会议软件把原声直接播放到扬声器，这部分外放也需要纳入参考覆盖的考虑。只知道同传软件自己播放了什么，未必足以处理现场的全部回声。
处理要跟上采集与播放的时间
播放声音经过设备、空气和房间反射，到达麦克风时会有一定延迟，也会发生音量与频率上的变化。
回声消除需要根据这些变化持续估计播放声音在麦克风里的对应成分，再进行抑制。及时、准确的播放参考，能为这个过程提供更充分的信息。[2]
播放译音时，也要尽量保留用户的新发言
真实会议经常出现一边听、一边补充的情况。例如，译音还没播放完，你就想说“我补充一点”。
因此，这套设计关注的不只是压低回声，还包括在播放与说话同时发生时，尽量保留新发言。声音质量、双向讲话和不同设备下的表现，都需要结合实际使用来验证。
四、声学回声与数字回授，需要一起处理
采集端回声消除处理的是扬声器经空气返回麦克风的声音。与此同时，ParleyVoice 也在声音路由上减少译音重新进入翻译流程的机会。
在 Windows 的系统声音采集路径中，应用会排除自身进程树的输出；双虚拟线路配置则检查端点是否被重复使用，区分“送给会议的译音”和“从会议接收的原声”。这些是当前代码中已有的路由保护。[5]
它们与采集端回声消除相互配合：前者减少数字线路中的回灌，后者针对物理播放返回麦克风的回声。
对用户而言，我们希望最终体现为更简单的体验：译音播放时，系统尽量避免把它再次当成新发言；用户开口时，自己的话能够清楚地进入翻译。
五、让清晰的声音成为同传的一部分
专业的同传体验，需要模型、采集、播放和音频路由共同配合。
低延迟让译音尽快到达；合理的回声处理，让模型更准确地接收到真正需要翻译的声音。两者一起改善的，是人们能否自然地听、说和回应。
ParleyVoice 正在围绕这样的目标完善音频处理：让采集端了解实际播放内容，减少回声进入模型，同时把不同方向的声音送到正确的位置。
我们希望用户把注意力留给正在交流的人，让声音处理安静地完成自己的工作。
本文介绍采集端回声消除的设计思路。相关增强链路的完整效果仍需按设备与音频模式验证和完善，实际可用能力以所用版本为准。[4]
技术资料
- Google Workspace：声学回声消除说明。
- WebRTC 音频处理接口：采集流与播放参考流。用于说明通用音频处理原理，不表示产品采用了该项目的具体实现。
- Microsoft：采集端与回声消除播放参考端点。
- 产品设计依据：ParleyVoice
release/1024音频架构与默认路径说明（内部工程文档，公开发布不附仓库链接）。本文按设计方案介绍，不把它写成所有默认路径均已完成的效果。 - Windows 系统声音采集范围与双虚拟线路端点校验为当前客户端路由保护逻辑（内部实现说明，公开发布不附仓库链接）。