前阵子替一家远程会议终端厂商处理样机回退问题测试工程师反复提了三个意见背景噪声太吵、本地扩声啸叫、视频通话回声太明显。这三个问题看着独立实际全都砸在音频处理链路上。常规做法是挂软件插件逐个压结果压住噪声就丢了人声清晰度压住啸叫又让声音发闷始终找不到平衡点。我最后把方案改成 A-59F 一体化 DSP 模组板载 AI 降噪、消回音AEC和防啸叫AFC三套实时算法由独立 DSP 完成全链路处理主控只负责下发控制指令问题一下子收敛了。这篇文章是我基于 A-59F 做的完整开发记录涵盖硬件接线、参数调试、声学评测和现场排障供做会议系统、音视频一体机、直播音频设备以及嵌入式语音方案的工程师直接参考。1. 选型与整体设计思路1.1 为什么选“一体化”而不是自己搭算法很多团队的第一反应是算法库不是到处都有吗降噪有开源方案回声消除也有现成库为什么非得用模组我的回答是算法能跑到产品里和算法能稳定跑在量产产品里中间差了十万八千里。先说资源问题。AI 降噪模型哪怕再轻量也要占用不小的算力和内存带宽。把它跑在主控芯片上意味着要跟业务逻辑抢 CPU而且音频处理要求低延迟操作系统的线程调度稍微抖动一下声音就会出现卡顿。回声消除更苛刻它需要参考信号与麦克风信号严格同步如果中间经过操作系统缓冲延迟一抖自适应滤波器就很难收敛回声不但消不掉还可能越消越乱。A-59F 的思路是把音频链路完全交给独立 DSP。麦克风进来、扬声器参考进来在 DSP 内部完成降噪、AEC、AFC、增益管理再输出干净的音频给后端。主控芯片不参与实时音频运算只通过串口发指令、查状态。这样一来延迟是确定的DSP 内部处理延迟通常在十几毫秒以内叠加功放和扬声器路径也完全可接受稳定性也是可验证的算法不会被系统负载影响。对于做产品的团队这其实就是把不确定性最高的部分交给一个成熟的音频处理核心自己专注在业务功能上。另外还有一个常被忽略的点算法迭代维护。自研算法意味着你要持续投入人力跟踪论文、复现模型、调参、适配不同声学环境还要处理各种极端情况。而模组方案的算法已经经过厂商多轮打磨用户拿到的是参数接口而不是算法源码省下来的维护成本非常可观。考虑到音频算法人才难招、培养周期长这个账很容易算。1.2 典型应用场景与选型确认A-59F 这类模组适用的场景比大多数人想象的要广。我把实际接触过的项目归了几类会议一体机和视频会议终端。这是最典型的场景扬声器开外放时回声严重会议室空调、风扇又带来稳态噪声人一多还有键盘声、翻纸声这些瞬态噪声。直播、内容创作设备。主播在房间说话麦克风靠近嘴边但房间里的电脑风扇、空调、甚至是窗外噪声都会被拾进去。这里的痛点是降噪不能损伤人声否则声音听起来不自然。KTV 包厢、教学扩声、养老机构呼叫对讲。这些场景扬声器功率大、麦克风距离近啸叫风险极高对 AFC 的实时性要求很高。医疗病房呼叫、电梯对讲这类远场拾音场景。重点在降噪和清晰度让语音在嘈杂环境中依然可懂。选型时除了确认功能还要看模组提供的接口形态、采样率支持、延迟指标和控制接口。A-59F 支持模拟输入输出和 I2S 数字接口两种接法采样率覆盖 16kHz 到 48kHz会议模式用 16kHz 或 32kHz 够用且延迟更低音乐或演唱场景要用 48kHz 保证带宽。我建议在做系统框图之前先跟模组厂商确认好你的后端是模拟功放还是数字功放主控是什么平台需要几路麦克风输入这些决定了你选具体型号和配置版本。2. 三条算法管线的工作逻辑2.1 AI 降噪从谱减法到神经网络掩码要理解 A-59F 的降噪优势得先知道传统降噪差在哪。传统谱减法做的事情是假设噪声平稳估计出一个噪声底再从信号频谱里减掉。空调声、持续的风扇声这种平稳噪声谱减法确实能压但它本质上是“减”的操作减过头就会留下一种叫“音乐噪声”的残留听感像水烧开咕嘟咕嘟的毛刺声。更麻烦的是键盘敲击、关门声、椅子拖动这种瞬态噪声谱减法根本来不及估计等它反应过来噪声已经过去了而瞬态噪声恰恰是真实场景里最干扰听感的。A-59F 的 AI 降噪走的是掩码路线。它对音频做短时傅里叶变换得到时频谱然后把每一帧的频谱特征送入训练好的神经网络。网络输出的不是“减多少”而是一个时频掩码相当于一张“哪些是语音、哪些不是语音”的判决图。语音所在的时频单元保留非语音的时频单元压低。因为网络见过大量带噪语音和干净语音的配对数据它对语音的结构有先验知识所以能比较准确地守住语音频带把键盘声、餐具碰撞这种突发噪声识别出来压掉同时人声的完整度明显好于谱减法。不过 AI 降噪不是万能的它最大的副作用是“语音受损”。模型训练追求的是在标准数据集上的客观指标提升真实环境里人声的尾音、气声、辅音很容易被误判成噪声。所以 A-59F 把降噪强度做成了可调档位从关闭到最高共若干档。我在实际项目里的经验是永远不要一上来就开最大档。直播间场景我一般用中档既压掉房间的低频嗡嗡声又保住主播声音的气息感会议室如果是普通办公环境中档也够只有像机房里那种风扇噪声特别大的环境才需要用高档并接受人声略微受损的代价。2.2 回声消除的工程难点与参考信号回声消除的核心是自适应滤波器原理可以这么理解扬声器发出的声音经过空气、墙壁反射到达麦克风形成一条声学路径。算法拿一路“参考信号”——也就是即将送给扬声器的音频信号——去模拟这条路径估计出麦克风信号里属于扬声器的回声分量再把它减掉。思路听起来简单工程上有三个绕不开的难点。第一个难点是参考信号的接入位置。A-59F 有专门的参考输入口正常情况下要把它接到功放输出端或扬声器信号源端让 DSP 知道“扬声器此刻在播什么”。有些人为了图省事不接参考只靠降噪硬扛结果回声消不干净声音也发虚。还有些人接错位置比如从我后面会讲到的输出端直接引回参考口等于让算法参考了自己处理过的结果效果同样很差。第二个难点是双讲场景。通话时本地人在说话同时扬声器也播放着远端人的声音这就是双讲。如果算法没有双讲检测自适应滤波器在双讲期间会误以为本地语音也是回声把它一起减掉表现出来就是“对方一说话自己这边的话就被吃掉”。A-59F 内置了双讲检测机制检测到双讲时暂停滤波器更新保住近端语音。第三个难点是扬声器的非线性失真。便宜喇叭在开大音量时会产生谐波失真线性自适应滤波器估计不了这种非线性回声所以算法还需要非线性处理NLP来压制残留。但 NLP 是伤敌一千自损八百的手段压得太猛会把残存的近端语音也削掉。这提醒我们一件事功放增益和扬声器不要搞到严重过驱动否则再强的 AEC 也白搭我在排查章节会再展开。2.3 防啸叫的动态频点跟踪啸叫的成因是正反馈麦克风拾到扬声器的声音放大后从扬声器再放出又回到麦克风循环增益一旦超过 1某个频率的能量就滚雪球一样增长变成刺耳的尖叫。传统方案是在检测到啸叫后用固定陷波器把那个频点挖掉问题在于反应慢——啸叫已经响起来才去挖房间里的人已经被炸了一遍而且啸叫频率会随距离、人走动漂移固定陷波器很容易挖错。A-59F 的 AFC 处理逻辑不一样。它持续监视麦克风信号各个频点的能量变化趋势如果某个频点的能量在短时间内快速上升就预判“这个点有正反馈风险”随即对这个频点做窄带抑制把增益压下来。同时它还会整体动态管理麦克风增益在啸叫风险高的时候收一收等系统稳定了再慢慢放开。这样做的实际效果是啸叫在将起未起的阶段就被按住了现场听到的只是一声很短的闷响而不是持续的尖叫。调试 AFC 时要注意一个细节它和降噪、AEC 在 DSP 内部是串行处理的互相耦合。AFC 调整麦克风增益会改变送入 AEC 和降噪的信号电平降噪模块处理之后又会改变最终输出的动态。所以在现场改任何一个参数都要完整走一遍全链路验证不能只看单项指标。我见过有同事单独把 AFC 深度调到最高结果啸叫确实没了但人声也轻了很多整个会议听起来像人躲在门后说话。3. 硬件接线、供电与音频路径设计3.1 接口定义与供电注意事项A-59F 对外接口一般包括模拟麦克风输入通常是差分、参考信号输入、模拟主输出、串口控制UART以及电源和地。我拿到的版本是双麦克风差分输入加一路参考输入、一路模拟主输出。差分输入的好处是共模抑制能力强麦克风走线稍长也不容易引入干扰前提是前端信号源确实是差分输出或者用单端转差分电路。供电这块我特别想多说两句。模组标称 5V但实际工作电流会随音频输出动态变化如果供电的开关电源纹波偏大或者走线太长导致压降DSP 工作就不稳定。我建议用 LDO 单独给模组供电纹波控制在 50mV 以内并且尽量不要和功放共用同一路电源。第一版样机我就是为了省成本让模组和功放共用一个 DC-DC 输出结果一放低频重的音乐整机偶发重启。后来把模组供电换到独立 LDO问题就再没出现过。另外模拟地和功率地在 PCB 布局上建议做星型接地所有模拟电路参考地从一个点引出功放地单独走宽铜箔在电源入口单点汇合这样可以避免地环路引入 50Hz 底噪和随机爆音。3.2 模拟链路增益与参考信号取样音频系统的成败往往在模拟链路不在算法。麦克风的输出电平远低于模组输入的线电平标准必须经过前置放大。前级增益的设置要注意两点一是要留出余量不能把增益推得太满最好留 12dB 左右的余量防止人突然提高音量或者离麦克风很近时产生削波二是前级运放本身的底噪要足够低否则噪声会被算法当成正常信号一起处理。我遵循的原则是让正常说话的音量在模组输入口达到约 -6dBFS 左右既保证信噪比又给突发大音量留出空间。参考信号的取样位置也值得单独说。A-59F 的参考输入要反映“扬声器实际在播什么”所以最理想的取点是从功放输出端并联取样而不是从 DSP 模拟输出端引。如果从模组输出端引回去参考信号里已经包含了 DSP 处理的结果算法就会陷入一个错乱的环路。还要注意参考信号的电平不能太高或太低通常要经过电阻分压网络衰减到线电平范围幅度过高会在参考输入口产生削波导致 AEC 误判。这个细节直接关系到回声消除效果我放到后面排查章节里细讲这里先记住结论参考信号必须取自功放输出侧电平要匹配。3.3 控制接口、预设模式与状态查询A-59F 的 UART 控制接口波特率常见配置是 115200。协议形态大同小异一般都是帧头加命令字加数据区再加校验的结构具体每个命令的字节定义要以厂商协议手册为准。命令类型主要分三类参数配置、状态查询和预设切换。参数配置用于设置降噪强度、AEC 开关、AFC 深度、麦克风增益、噪声门阈值这些。状态查询用于读取模组运行状态、算法使能情况和固件版本上电后第一件事就应该是发一条版本查询命令确认串口通不通、模组活着没有。预设切换是我用得最多的功能可以把一整组参数保存成一套预设通过一条命令切换。我之前给一个客户做会议室和 KTV 包厢共用的设备就在模组里存了三套预设会议模式、演唱模式和监听模式。客户不会调参数没有关系只需要在界面上点模式切换底层发对应的预设命令即可。这个设计在交付验收的时候非常加分。4. 参数调试与声学实测流程4.1 从直通开始的调参顺序拿到模组第一步不是调参数而是把默认配置跑通。默认配置一般比较折中降噪中档、AEC 开启、AFC 开启、麦克风增益适中。先把线接好、上电、用耳机监听模组输出确认音频链路通畅、没有明显杂音然后再进调试。我的调参顺序很固定从后往前先把所有算法都关掉只保留直通确认原始模拟路径的底噪和失真水平。这一步非常重要因为如果直通状态下声音就已经脏了后面所有算法都救不回来。直通确认干净之后先打开 AEC用扬声器放音乐、对着麦克风说话验证回声消除效果再打开 AFC逐步加大扬声器音量观察啸叫抑制是否及时最后打开降噪把强度从低到高一档一档试找到音质和降噪效果的平衡点。为什么一定要这个顺序因为如果一开始就把降噪开到最大你根本分辨不清听到的语音损伤是降噪造成的、还是前级增益不对造成的。逐个叠加、逐项定位才能知道每个模块各自贡献了什么、代价是什么。4.2 典型场景参数对照我把在几个实际项目中沉淀下来的参数组合整理成表作为工程起点供参考。注意这只是起点不是终点声学环境千差万别同样的参数在吸音好的会议室和混响重的毛坯房里效果完全不同。参数项会议模式演唱模式监听模式降噪强度中档低档中档AEC 开关开开开麦克风增益中等较高中等AFC 抑制深度中高中噪声门阈值低关闭低演唱模式把降噪调低是为了保留人声的气息和尾音细节AFC 调高是因为 KTV 场景扬声器功率大、麦克风离得近啸叫风险更高监听模式则适用于直播和内容创作既要压环境噪声又不能损伤人声质感。调用前还要确认采样率设置演唱和监听建议用 48kHz会议用 32kHz 或 16kHz 就够还能降低延迟。4.3 主观听感与客观指标如何平衡参数调完不能只靠耳朵收货还要用客观指标兜底。我习惯测三类指标信噪比、总谐波失真加噪声THDN、以及回声消除的 ERLEEcho Return Loss Enhancement回声返回损耗增强。信噪比测试是在安静环境下播放一段语音比较语音段和静音段的电平差。一般来说开启降噪后信噪比应该有明显提升比如从原来的 40dB 以下提升到 55dB 以上如果提升不明显先检查前级增益而不是加大降噪档位。THDN 用 1kHz 正弦信号测正常范围在 1% 以下超过这个值就要怀疑是前级削波或者模组输出电平过高。ERLE 的测法是播放扬声器信号但不播放近端语音测量模组输出中残留的参考信号成分目标是比原始回声降低 30dB 以上。现场没有专业音频分析仪的时候我有个土办法拿手机放音乐当扬声器信号源让麦克风正常拾音然后用耳机监听模组输出。如果音乐声几乎听不见只有近端人声说明 AEC 和降噪配合得好如果还能听到音乐尾巴或者人声下层的音乐声在抖说明回声消除有问题。这个方法不精确但用来快速判断问题方向足够用了。5. 实战踩坑记录与问题排查速查表5.1 三个印象最深的翻车现场第一个坑是参考信号取样位置。最早一版图纸为了走线方便我把参考信号从模组的模拟输出端直接引回参考输入想着“反正都是同一路音频绕一圈也行”。实测发现回声消除效果很差而且人声一响回声反而变得很奇怪。原因是模组输出端口的信号已经是 DSP 处理后的结果拿它当参考等于告诉算法“扬声器播的是处理后的信号”和真实声学路径对不上。改成从功放输出端并联取样之后回声消除效果立刻好了一个数量级。第二个坑是地环路。某次项目现场样机一接上客户的大屏就出现持续的低频嗡声关掉大屏供电就安静。排查了很久才发现是大屏和模组各自接了不同的地形成环路。解决办法是把模拟地和数字地重新整理成星型接地在大屏连接处做单点接地。这个案例让我明白音频模组不是孤立器件它与系统其他部分的电位关系直接影响底噪表现。第三个坑是降噪强度开太高导致语音发飘。有个客户会议室空调噪声特别大我图省事把降噪直接拉到最高结果客户试听反馈人声“像隔了层纱布”语音一出现就感觉发飘。后来把降噪降一档同时把麦克风前级增益提高一点让信噪比在进入算法前就好一些问题就解决了。这让我牢牢记住一个原则算法是最后一道防线前级模拟链路做得好算法的负担才能小。5.2 常见问题排查速查表现象可能原因排查与解决方法上电后无输出供电异常 / 串口未初始化成功先查电源电压和纹波再发版本查询命令确认串口是否正常人声发闷、语音发飘降噪强度过高降低降噪档位适当提高前级增益改善输入信噪比啸叫仍然明显AFC 深度不足 / 麦克风增益过高增大 AFC 抑制深度降低麦克风增益并拉开麦克风与扬声器距离回声消除不干净参考信号接错位置 / 功放削波确认参考信号取自功放输出侧检查功放增益避免过驱动底噪大、有低频嗡声地环路 / 前级运放噪声整理星型接地更换低噪声前级运放双讲时本地语音被吃双讲检测阈值不合适调整双讲检测灵敏度参数适当降低 AEC 收敛速度声音断断续续噪声门阈值过高降低噪声门阈值或关闭噪声门试听对比5.3 排查方法论先看链路再看算法最后分享我的排查习惯。遇到任何音频问题先把算法全部关掉只留直通然后用三段式检查信号源干不干净、链路增益对不对、输出有没有失真。直通有问题那一定在模拟电路不要怪 DSP直通没问题打开算法才有问题就逐个算法开开关做二分定位。这个方法看上去笨但非常节省时间。很多人在问题出现时第一时间去调算法参数结果调了半天没效果回头才发现是电源纹波超标或者参考信号接错。顺序对了问题往往几句话就能锁死。说点实操心得收尾。A-59F 这类一体化模组最大的价值是让团队不用在音频算法上从零投入但它的上限仍然由整体系统决定前级模拟电路、功放选型、扬声器摆位、房间声学任何一个环节拖后腿算法都救不回来。我自己在做项目交付时会特别注意客户现场的扬声器与麦克风之间的距离和朝向这是影响啸叫和回声的最关键物理因素。另外养成“改一个参数就完整验证一遍全链路”的习惯会让你的调试少很多返工。最后再分享一个小技巧给模组的每个预设模式都起一个业务层面的名字比如“报告厅模式”“会议室模式”让客户在界面上直接选场景而不是面对一堆数字参数。这样既降低使用门槛也减少后续因为误操作导致的客诉。