语音打断即时响应：全双工链路、AEC与VAD工程实践

1. 打断不是“听见就停”先把这条链路上的毫秒账算清楚“语音打断即时响应”这八个字看起来像是一个交互体验问题实际上是一个彻头彻尾的工程问题。我在给小智音箱做这套能力的时候最初的想法也很朴素检测到人声就把播放停掉然后开始收音识别不就完了结果第一版跑出来用户说完“等一下”之后愣了两秒音箱才闭嘴中间还把自己的播报内容录进去当成了用户输入识别出一堆莫名其妙的字。这件事让我彻底明白语音打断从来不是单点功能它是一条从麦克风到扬声器、横跨采集、前端处理、唤醒、识别、决策、播放控制六个环节的全双工管道。任何一个环节还停留在“半双工”的思维里即时响应就是一句空话。小智音箱这套方案的目标定得很明确用户在音箱播报过程中开口从人声起始到音箱停止发声控制在 300 毫秒以内并且保证打断之后紧接着说出的指令能被正确接住不丢字、不串音、不误触发。适合谁看如果你正在做带扬声器的语音交互设备——智能音箱、带屏终端、车载语音、服务机器人或者你只是想把一个语音助手从“对讲机模式”改成“电话模式”这套思路基本可以直接搬。下面我按自己实际调试的顺序把这条链路拆开讲。1.1 一次“打断”在系统里究竟发生了什么先把动作序列摊开。用户开口的那一刻物理世界发生的是声波进入麦克风同时音箱自己的声音也在同一空间里反射、混响、被麦克风采到。所以麦克风拿到的信号是“用户语音 自身播报的回声 环境噪声”的叠加。系统要做的第一件事不是识别而是把属于自己的那部分减掉这就是回声消除。减完之后剩下的残差信号进入语音活动检测判断“现在有没有人在说话”。判定成立后状态机从 SPEAKING 切到 INTERRUPTED播放通道立刻执行淡出、清空缓冲区、停止 TTS 流式拉取。与此同时识别通道开始把音频帧喂给流式 ASR等首字结果出来再决定是回应、是续播、还是重新理解意图。这里有个容易被忽略的细节“停止播放”和“停止发声”不是一回事。软件层面把播放状态置为停止只花了不到 1 毫秒但音频硬件里还压着几十到几百毫秒的缓冲数据扬声器振膜还得把这部分放完才真的安静。如果你的播放缓冲设了 200 毫秒抗抖动那用户听到的“闭嘴延迟”就至少多了 200 毫秒。所以做即时响应的第一步是把播放链路的水位降下来而不是去优化 VAD 算法。我在第一版里就栽在这儿VAD 判定只用了 30 毫秒但播放环形缓冲开了 400 毫秒用户主观感受到的延迟是“差不多半秒”怎么调阈值都没用。后来把缓冲压到 80 毫秒配合小分片拉流主观感受立刻不一样了。1.2 延迟账本把端到端时延拆成可优化的五段做性能优化最怕“整体感觉慢”。我习惯的做法是先建一张延迟账本把每一段的耗时单独测出来再决定往哪儿投人力。环节优化前实测优化后实测主要手段麦克风采集 前端处理AEC/NS/AGC45 ms18 ms帧长 10 ms、前端管线合并、关闭非必要重采样VAD 判定与确认120 ms30 ms双门限 连续帧确认替代长 hangover打断决策与状态切换8 ms3 ms状态机去锁、异步事件派发播放停止与缓冲清空380 ms60 ms降低播放水位、硬件淡出、分片拉流反馈提示提示音/灯效0 ms12 ms打断瞬间先给短提示音合计人声起始 → 完全静音约 553 ms约 123 ms—注意这张表里“合计”不等于各项简单相加因为采集、VAD、决策是流水线并行推进的实际端到端是流水线的最长路径加上不可并行的串行段。这张表最有价值的地方是它告诉我瓶颈根本不在算法。VAD 从 120 毫秒优化到 30 毫秒用户感知提升有限播放链路从 380 毫秒砍到 60 毫秒用户立刻说“反应快了”。这就是为什么我一直劝做语音交互的朋友先量再改别凭直觉调参。顺带说一个反直觉的结论——打断的“即时感”并不完全由真实延迟决定。我们在打断瞬间加了一个 12 毫秒的极短提示音类似轻微的“哒”同时把灯环从呼吸态切成常亮。用户主观评价的响应速度提升了接近一个档次尽管真实延迟只多了 12 毫秒。原因是人耳对“系统有没有收到我的信号”这件事极度敏感给一个即时反馈等待就被感知成了“它在准备”而不是“它没听见”。2. 回声消除与双讲检测让音箱在自说自话时还能听清你如果只允许我保留一个技术点来保证打断可用我会毫不犹豫选回声消除。原因很简单音箱播报时的音量通常是用户说话音量的两三倍在自己的声音里找一个更小的声音信噪比是负的。AEC 做不好后面所有的 VAD、ASR 全部是在噪声上做文章。2.1 AEC 为什么是打断的前置条件而不是可选项AEC 的经典结构是自适应滤波器把“即将送给扬声器的数字信号”作为参考信号 x(n)麦克风信号 d(n) 里包含回声路径卷积后的结果滤波器估计出 ŷ(n)两者相减得到残差 e(n)。理想情况下 e(n) 里只剩用户语音和环境噪声。工程上有几个点必须提前想清楚否则调不出来参考信号要取“功放之前但经过全部数字处理之后”的那一路。如果你取的是 TTS 输出但中间还有音量调节、EQ、限幅那参考信号和真实回声就对不上滤波器永远收敛不了。我们踩过一次音量归一化模块放在了取参考点之后用户把音量调大AEC 立刻失效误打断率飙升。延迟对齐要做而且要持续做。数字链路的缓冲、DAC/ADC 的转换、声学传播距离加起来可能让参考信号比真实回声早 20 到 60 毫秒。我的做法是启动时用互相关扫一遍 ±80 毫秒范围估计出主延迟运行中每隔几秒做一次轻量的延迟漂移校正。延迟对不齐滤波器阶数再高也没用。尾长要按房间算不是按芯片算。普通客厅混响时间大约 300 到 500 毫秒滤波器尾长至少要覆盖这个量级。我们用 256 毫秒的频域分块自适应滤波配合后级的残余回声抑制在中等混响房间够用空旷客厅或者瓷砖卫生间就得加长。这里有个很现实的取舍尾长越长、滤波器越多算力消耗线性上涨。小智音箱最后跑在定点 DSP 上为了给 ASR 留算力我们把 AEC 限制在 16 kHz 单通道、分块频域实现实测残差抑制大约 25 dB够用但不奢侈。如果你的产品定位是远场大房间这一块预算别省。2.2 双讲状态下的漏打断与误打断本质是同一枚硬币双讲double-talk指的是用户说话和音箱播报同时存在。这时候自适应滤波器会试图用参考信号去拟合用户语音导致滤波器系数发散回声反而消不干净。标准做法是双讲检测一旦判定双讲就冻结滤波器自适应只用当前系数做减法同时把残余回声抑制的强度调高。问题在于双讲检测的灵敏度直接决定了两个错误指标判得太敏感正常的播报途中被噪声误判成双讲滤波器长期冻结慢慢跟不上环境变化回声泄漏变大最终导致误打断系统以为用户说话了。判得太迟钝用户真的插话了滤波器还在那儿拼命拟合用户的声音把用户语音当成回声消掉一部分导致漏打断或者打断后识别不全。我的经验是把这两件事分开处理不要指望一个检测器同时解决双讲检测服务于 AEC 稳定性打断判定服务于交互体验。前者可以保守一点宁可少冻结后者可以激进一点宁可多判一次再用后面的确认机制兜底。混在一起调最后一定两头不讨好。还有一个隐蔽的坑残余回声抑制会削掉用户语音的开头。用户第一个字的声母能量本来就低如果抑制模块的增益下降太快打断后识别出来的第一个字经常丢比如“把音量调到五”识别成“音量调到五”。解决思路是让残余回声抑制的状态和 VAD 联动——VAD 一旦起跳立刻把抑制增益恢复宁可短暂泄漏一点回声也别把用户的开头吃掉。3. VAD 与打断判定怎么区分“插话”和“咳嗽一声”VAD 是打断的触发器但只靠 VAD 做打断产品一定做不下去。我家客厅实测一小时内电视对白、家人交谈、碗筷碰撞能触发几十次误打断。所以真正的打断判定必须是 VAD 加上下文的多级门控。3.1 从能量门限到模型打分单靠哪一个都不够我试过的方案大致三代第一代是能量加零率简单粗暴安静环境好用一开电视就废。第二代是通用 VAD 模型帧级输出语音概率抗噪好了很多但在“有人声但不是在跟设备说话”的场景下依然会误触发。第三代是VAD 打分 播报状态 自激抑制的组合判定。这里重点说自激抑制这是我认为最划算的一招。原理很土如果 ASR 识别出来的内容和音箱正在播报的文本高度相似那这句话一定是自己说的不是用户说的。做法是把当前播报文本的滑动窗口比如最近 5 秒的内容和流式 ASR 的中间结果算字符级重合率超过阈值就判定为自激直接把这次打断请求丢弃。这招解决了一个很恶心的场景用户把音量开到 90%AEC 残差压不住系统听到自己的声音ASR 识别出“今天的天气”之类的内容然后又触发一次打断再播报一遍形成自激循环音箱会像卡带一样反复重复同一句话。上线前我们在实验室没复现出来是用户音量开大才暴露的。判定链路的完整顺序我是这样排的AEC 之后的残差信号进入 VAD输出逐帧语音概率。概率超过起跳阈值我们用 0.6连续 3 帧30 毫秒才认为起跳。起跳后进入 200 毫秒确认窗口窗口内累计语音帧占比超过 50% 判定为“有效人声”。有效人声进入自激抑制比对命中则丢弃。通过后触发打断同时把音频帧回溯 200 毫秒一起送给 ASR——这一步很关键否则用户开口的头 200 毫秒就丢了。第 5 步的回溯缓冲是我后来补上的。之前是检测到才把音频送进识别用户“帮我”两个字经常识别成“我”体验很差。加了环形回溯缓冲之后打断后首字完整率从 82% 提到了 97% 左右。3.2 打断门槛的参数整定必须带着场景一起调参数这玩意儿没有普适值必须绑定场景。我给小智音箱定的三档策略供你参考场景VAD 起跳阈值连续确认帧确认窗口说明安静室内40 dB SPL0.553 帧150 ms追求快靠自激抑制兜底普通家居40–55 dB SPL0.654 帧200 ms默认档强背景音电视/厨房0.755 帧300 ms宁可慢一点别乱插嘴这三档不是一个静态配置而是根据前端噪声估计的长期统计自动切换。切换要有迟滞否则在噪声边缘会来回抖用户会感觉音箱“一会儿灵一会儿聋”。提示确认窗口拉长会带来一个副作用——用户在窗口期内如果只说了一个很短的词比如“停”可能被判定为时长不足。解决办法是给单字指令开后门窗口内检测到能量突发且时长虽短但谱形符合人声仍然放行。还有一个必须写的保护机制打断冷却。一次打断完成后 1.5 秒内不再接受新的打断请求除非检测到明确的唤醒词。不加冷却用户在打断后马上说指令系统可能把指令的后半段又当成一次新打断状态机来回跳最后谁也不知道该听谁的。4. 全双工管道改造把串行的“说完再听”拆成并行大部分语音助手最初都是半双工唤醒、收音、识别、播报串行执行播报期间麦克风直接关掉或者数据丢弃。要支持打断就必须把这条串行链改成并行管道而这个改造牵扯的东西比想象中多。4.1 音频通道的缓冲水位与丢弃策略改造的核心是让播放和采集同时活着中间靠 AEC 隔离。这里要设计三件事第一播放侧的水位。水位高抗抖动但停止慢水位低响应快但网络抖动或者解码卡顿会造成爆音。我的做法是分层网络流式 TTS 拉取用一个较大的缓冲1 到 2 秒可以静默预拉解码输出到播放硬件之间用一个小缓冲60 到 100 毫秒。网络卡顿体现在大缓冲被消耗不会直接影响播放的连续性而打断只影响小缓冲速度快。第二缓冲区清空策略。打断发生时小缓冲里的数据必须立刻丢弃并且不能是“标记作废”式的软清空——有些音频框架的清空操作要等当前 DMA 周期结束实际会多出几十毫秒。我们最后用的是硬件层面的淡出加复位先做 10 毫秒线性淡出避免咔哒声再复位 DMA 指针。第三识别通道的持续供流。播报期间 ASR 的流式连接不能断否则打断后要重新建连首字延迟直接翻倍。我们让识别通道在播报期间保持“热连接”只是把结果丢弃。这样打断后音频帧一进来就能出中间结果。这三件事做完我遇到的最大的一个坑是时钟漂移。播放时钟和录音时钟来自不同的晶振长时间运行会偏移导致 AEC 的参考信号和回声慢慢错位半小时后回声消除效果肉眼可见地变差。解法是定期用互相关做微小重采样校正或者直接用同一个时钟源驱动收发。这个坑在短时间测试里完全看不出来一定要跑长稳。4.2 播报被打断之后那句话还要不要接着说完这是产品逻辑问题但技术实现上必须提前留好接口。我的处理分三种情况完全放弃用户说了明确的新指令比如“别说了放首歌”。这时候丢掉播报上下文直接执行新意图。断点续播用户说的是“等一下”“稍等”这类暂停词。系统记住当前播报的文本位置和音频偏移等用户说“继续”时从断点恢复。实现上要在打断瞬间记录已播字符数或已播时长续播时从对应位置重新合成注意别把一句话切在半个词上要回退到最近的标点或者短语边界。槽位继承这个最复杂也最有价值。比如音箱正在说“好的闹钟已经定在早上七点明天……”用户插话“改成八点”。这时候新指令是一个“修改”意图但它依赖上一轮的上下文当前有个七点的闹钟。我的做法是给会话状态维护一个槽位快照打断发生时把未完成的播报内容摘要成结构化槽位存起来新指令解析时优先和快照做槽位合并。不做这一步用户就得把整句话说全打断的体验优势就废了一半。实测下来槽位继承在“设闹钟”“调音量”“改定时”这几类指令上命中率最高也最容易让用户觉得“这音箱听得懂人话”。5. 实测复盘那些只在真实房间里才冒出来的坑实验室安静环境下打断成功率 98%到了真实家庭环境掉到 71%——这是我这轮开发里最真实的一课。下面这几类问题全部是上线前小范围实测阶段暴露的。5.1 六类典型误触发场景与处置场景表现根因处置电视背景对白频繁误打断VAD 判人声但非目标说话人提高阈值 方向性麦克风 自激抑制音箱大音量自激反复重复同一句AEC 残差泄漏 ASR 识别到自身播报文本与识别结果重合度比对咳嗽/关门声偶发打断瞬态噪声谱形类人声最短语音时长门限 谱平坦度判据儿童尖叫误打断且识别为空高频能量强、时长短高频段能量占比门控两人对话路过打断后识别出无关内容无人声定向打断后置信度不足则静默恢复播报用户说完立刻走开打断后无后续指令只有打断没有人声指令3 秒超时后回退到原状态并给轻提示第五行那个“静默恢复播报”我觉得挺有意思。最初的逻辑是打断后如果 3 秒内没识别出有效指令就给一句“我没听清”。实测发现这非常烦人——用户只是路过说了句话音箱突然冒出一句“我没听清”像个神经质。后来改成静默恢复把刚才被打断的那句话接着说完用户反而觉得自然。这个改动看着小用户满意度提升明显。第六行也值得说打断之后如果用户什么都不说状态机不能一直挂在 INTERRUPTED 上。我们设了 3 秒超时超时后回到打断前的状态。但这里有个细节恢复时要重新播报一小段“刚才说到……”的引导语吗我的选择是不加直接从断点续因为加引导语会让原本 5 秒的播报变成 8 秒反而更烦。再补一个只有真实房间才会遇到的情况多人同时说话。两个人一起开口AEC 和 VAD 都能正常工作但 ASR 会识别出一锅粥。我们的处理是打断照常触发保证即时响应但在识别结果置信度低于阈值时不做任何回应只把灯环提示一下等用户再说一遍。宁可沉默也别答非所问。5.2 一套可以照着跑的打断能力验收清单最后把我自己用的验收方法列一下这套流程跑完基本上线不会出大问题。测试维度组合环境噪声安静35 dB、正常家居45–55 dB、电视开启、厨房抽油烟机音箱音量30%、60%、90% 三档说话距离0.5 m、1.5 m、3 m说话方位正对、侧向 45°、背后 90°打断时机播报第 1 句、第 3 句、最后一句说话人成年男声、成年女声、儿童、老人核心指标打断响应时延 P50 和 P90我用的是播放通道静音时刻减去人声起始时刻用录屏加音频对齐人工标注 200 次取分位打断成功率有效人声触发打断的比例误打断率每小时无意识触发的次数这个指标比成功率更影响口碑打断后首字完整率打断后意图正确率我给自己定的验收线安静环境下响应时延 P90 ≤ 200 毫秒、误打断 ≤ 0.5 次/小时正常家居环境下 P90 ≤ 350 毫秒、误打断 ≤ 1.5 次/小时。超出这个线说明还有环节没调好别急着发布。注意误打断率的统计一定要跑够时长至少连续 4 小时以上覆盖做饭、看电视、家人聊天这些真实活动。跑 10 分钟的测试数据毫无参考价值我自己就被“测试全绿、上线全是投诉”坑过一次。这套东西做下来我最深的一个体会是语音打断的难点从来不在“检测到人声”而在“确认这是对我说的”。AEC、VAD、阈值、状态机全部是在为这个判断服务。如果让我重做一遍我会把一半的调试时间花在自激抑制和上下文门控上而不是继续抠 VAD 的那几十毫秒。小智音箱现在的打断体验用户反馈最正面的一句话是“跟它说话不用等它说完”这句话背后其实是几十个参数和一堆在真实客厅里才会冒出来的边界情况。