最初发表(日文)于former.workstyle.tech.
在浏览器中构建基于语音的AI互动(avatars, voice bots, streaming AI)时,你会不可避免地碰到来自音频物理和浏览器执行怪胎的陷阱.
这篇文章汇编了我在产品开发过程中遇到的16个陷阱,按症状排列 → 原因 → 解决方案查询格式.
不必从上到下地阅读, Echo and Self-Resolution Issues
1.
Avatar Responds to its Own Voice (Deite) Symptom:TTS音频被麦克风取出,STT承认为用户语音,创建了自应回路.
原因:AEC(声回声取消)需要一个参考信号("声回声取消").
只有浏览器的官方回放路径(/WebRTC接收道)作为参考.
通过Web Audio API自定义回放不能可靠地发挥参考功能.
解决方案:从服务器返回TTS音频作为WebRTC远程轨道,并通过元素播放.
这消除了无文本比对工作的回声(测试:99秒连续演讲,0个错误的用户转弯检测).
2.
Echoes Are Gone,但与"神通神通"Distorts My Voice and Decause Miscovery Synmptom同时发言:仅在双重发言时,适当的名词才会被弄得一团糟(例如"QQ"-"Q"),特别是在单词开头.
原因:基本AEC取舍.
为了取消回声,AEC在双重语音中压制/扭曲近端(用户)音频.
解答:分出三层: 1 增加mic Opus比特率并启用FEC(见Pitfall 13) 2 向STT提供词汇提示(见单独的文章:使用"最近avatar语"作为",不是字典") 3 指令LLM:"输入是STT有潜在错误的抄录.
将非自然词解释为口语相近的词汇并添加确认提示".
3.
Can't Instant Audio from Other Apps(Music, Videos) Symptom: 由代理开通的YouTube视频的音频/解说不断被STT转录.
原因:浏览器AEC只能引用同一分页/app播放的音频.
其他过程的音频从人类的语音到麦克风是无法区分的.
解决方案:没有技术银弹.
结合OS扬声器分离(例如:macOS"声音隔离";通过-被不支持的系统所忽略),耳机和下游噪声拒绝(LLM/tool-filtering)请求. "只有开始是未闻" 第4期.
在会话开始时, 之后正常工作。
原因: 有两种因素:(a) AEC趋同——AEC只在实际回放时才学习,因此未相容的双重语音会抑制用户的声音. (b) 坡道-Gain逐渐增加,使最初的言论过于安静。
解决方案: (a)在主会话前播放简短的问候/声音效果来训练AEC(装入屏幕对此是完美的). (b) 设置。
如果 STT 是服务器侧面, 音量起伏处理良好, 并且功能失效的 AGC 的下行最小 。
永远不要禁用。
5.
不能诊断“ 无回应” 问题症状: 不清楚问题是否关闭、 预处理丢失、 或服务器端的线索来猜测 。
解决方案:增加两个可观察点:1 服务器侧记录输入音频能/概率(10Hz.
将"完全沉默"与"扭曲的音频"区分开来. 2 用于实际传输流的UI分级表(读取与传输相同的流-不影响传输).
6.
启动 Mic Track 有原因"没有回应" 投诉症状: 执行遵循 spec ("mic off至按下按钮"),但用户期望"总是听".
原因: 设计合同和用户经验预期之间没有矛盾。
一个无声的音轨从"静室"到服务器看起来无法区分.
解决方案:与产品承诺对齐默认.
如果"总是听"是一个销售点,在初始化完成时(不是在连接期间——即中断中线对话)可以自动启用.
保持按钮作为哑巴切换.
铬 执行a