1. 为什么偏偏是plate reverb：先搞清楚这个效果器在杰理方案里的位置
做蓝牙音箱和便携Soundbar方案调试的朋友，应该都对“杰理”不陌生。我最近在一个模拟项目X里接到一个需求：蓝牙音箱在“音乐模式”下要增加一档空间感明显的音效，客户点名要板式混响（plate reverb），而且强调必须基于新版本SDK来做。我在旧版工程上顺手改过hall reverb，结果拿到新版本SDK一看，原来那套改法全变了，网上能搜到的资料又大多停留在两三年前的版本，折腾了两天才彻底摸清楚。
先别急着翻代码，得先弄明白一件事：plate reverb在杰理这套音频方案里，到底承担什么角色，和hall reverb、room reverb有什么区别。
1.1 板式混响和厅堂/房间混响的差别
板式混响是录音棚时代的老经典。物理上一块大金属板，换能器激发板面振动，再通过多个拾振器拾取反射声，形成一种非常致密、略带“金属光泽”的混响尾巴。它的特点不是模拟真实空间，而是制造有冲击力的空间感。
- hall reverb：模拟音乐厅，尾巴长、密度高、衰减自然，适合古典和氛围类内容。
- room reverb：模拟小房间，早期反射声明显，空间小、尾巴短，适合给人声加“贴身感”。
- plate reverb：密度极高、起音快、高频响应明亮，常用在摇滚人声、军鼓、电吉他上，能让声音“立起来”但不浑浊。
在蓝牙音箱这种小腔体设备上，真正缺的不是低音，而是“开阔感”。喇叭尺寸小、箱体容积有限，声音容易闷在壳子里。Plate reverb能给声音补一层高频细节丰富的环境声，让听感上“箱子变大了一圈”，这是它被客户点名的主要原因。
1.2 混响效果器在杰理音频框架中的串联关系
杰理蓝牙SoC的音频链路一般是：解码器 -> 采样率转换 -> EQ -> DRC -> 音效（混响/回声）-> 音量 -> DAC输出。在新版本SDK里，音效部分通常挂在一个叫“audio effect”的模块下，和EQ、DRC并列，但处理顺序有讲究。
我实际看的工程里，默认顺序是DRC在前、混响在后。这个顺序非常关键：如果DRC在前，它会先压缩动态，再进混响；如果混响开得大，湿声比例高，DRC的压缩反而会把已经加厚的混响尾巴压回去，听起来像“混响没开一样”。这个坑后面我会专门展开，先记住一点：改plate reverb之前，先看清楚它在整条链路里的位置。
另外还要区分单声道回音、立体声混响和plate reverb。旧版SDK里很多项目用的是“echo+reverb”二合一效果，听感上就是卡拉OK厅那种重复回声；plate reverb是多组全通滤波器加梳状滤波器的结构，尾巴密度和金属感完全不同。新版本里两者常常是独立的算法模块，不能混为一谈。
2. 新版本SDK改了什么：从代码硬编码到音效参数表
这次折腾最大的感受是：新版本SDK对音效的管理方式做了重构，不只是换个参数位置那么简单，而是把整个音效参数的存放和生效机制都改了。
2.1 工程目录和音效源码的位置变化
旧版本里，混响参数通常直接写在reverb.c或者effect.c里，打开文件，找到结构体，改几个数字，编译完事。新版本SDK把音效代码拆成了独立目录，我手上这个工程的结构大致是这样的：
sdk/ ├── apps/ │ ├── common/ │ │ └── audio_effect/ │ │ ├── effect_param.c // 音效参数表，plate reverb参数在这里 │ │ ├── effect_param.h │ │ └── effect_alg.c // 音效算法入口 ├── lib/ │ ├── audio_effect_lib.a // 编译好的音效算法库 │ └── ... └── tools/ └── effect_config_tool/ // 上位机音效配置工具注意一个关键区别：新版本直接把音效算法封装成了静态库（.a文件），源码只给接口和参数表。也就是说，你没法再像旧版那样去改算法内部的滤波器系数，只能通过参数表来控制算法行为。
刚开始我有点不适应，但仔细想想是合理的。算法库化之后，不同产品共用同一套算法，不会出现两个项目各自改坏了DSP逻辑的情况；参数外置之后，调音师不用碰代码，改完参数表重新编译即可。问题是，你得重新学习这套参数表怎么用。
2.2 宏开关和编译链路：确认你开的确实是plate reverb
新版本SDK的音效总开关通常有几层宏，一层没开到位，改半天参数都不生效。以我调试的工程为例，需要确认这几个地方：
// 顶层功能开关 #define AUDIO_EFFECT_ENABLE 1 // 音效类型选择：有些工程把hall/room/plate做成枚举 #define AUDIO_EFFECT_REVERB_TYPE AUDIO_EFFECT_REVERB_PLATE // 混响独立开关 #define AUDIO_EFFECT_REVERB_ENABLE 1这里要特别提醒：不同分支的SDK宏名未必完全相同。有的版本用EFFECT_TYPE_SELECT，有的用REVERB_MODE_CFG，而且AUDIO_EFFECT_REVERB_TYPE这一项，并不一定都定义了AUDIO_EFFECT_REVERB_PLATE这个枚举值。我就遇到了宏列表里只有hall和room，没有plate的情况，后来翻了工程目录下的头文件才发现，新版本用REVERB_TYPE_PLATE = 3这样的裸数字代替。
所以拿到一个新SDK，第一件事不是改参数，而是把audio_effect相关头文件里的枚举定义都过一遍，确认你用的这个版本有没有暴露plate reverb的开关。如果宏是裸数字，建议顺手写一行注释说明，免得交付之后别人看不懂。
2.3 参数到底存在哪里：.c数组、配置工具导出和Flash烧录路径
新版SDK最值得注意的变化是音效参数可以走“上位机工具导出”的链路。工具里调好plate reverb的预延迟、混响时间、阻尼等参数，点击导出，生成的是一段c语言数组，直接替换effect_param.c里的默认值。
这个数组通常长这样：
const u16 plate_reverb_param_table[] = { /* pre_delay_ms, decay, diffusion, damping, wet_ratio, hp_cutoff */ 0x001E, 0xB000, 0x0060, 0x0028, 0x0030, 0x000A, };但实际工程里，参数个数远不止这些，因为每套音效还分“音乐模式”和“语音模式”，每个模式又可能对应不同的采样率。数组的排列顺序必须跟工具定义严格对应，否则参数会错位。一般工具导出的文件头会带版本号和校验码，如果烧录后发现效果完全不是那么回事，先检查导出的参数表是否匹配当前SDK的音效库版本。
参数最终会有一部分烧录到Flash配置区，开机时加载到RAM。这就引出另一个问题：旧版SDK改参数只要改代码、重新编译；新版本如果你改了Flash里的配置项，但代码里没同步更新参数，那么运行时到底以谁为准？不同SDK规定不同，我的建议是开发阶段一律走代码里的参数表，确认无误后再决定是否启用Flash配置覆盖功能，避免两边不一致导致“参数改了却听不出变化”。
3. 动手修改前的准备工作：版本、芯片资源和编译环境三件事
没做过嵌入式DSP调音的人可能觉得，改音效参数不就是调几个数字吗？其实真实项目里，问题往往出在动手改之前。准备工作没做够，后面全是坑。
3.1 先确认SDK版本和音效库版本
这是整个排查链路的第一环，也是我这次栽过的跟头。第一次我直接在某个旧SDK上按新版本的思路去改，找了半天没有effect_param.c，才知道自己用的库根本不对。
确认版本有三个层面：
- SDK压缩包的版本号，一般在文件名里，比如
AC69x_BT_SDK_V2.x.x。 - 音效库
lib/audio_effect_lib.a的编译时间戳，可以用strings命令或者二进制对比工具查看。 - 上位机工具的版本号，工具和音效库通常是配套发布的，两者版本不一致，导出参数就会错位。
具体到你手里的项目，最稳妥的办法是看release notes。如果release notes里提到了“音频效果模块重构”或“音效参数导出方式变更”，那就要按新流程走。要是完全没有头绪，可以用工程里自带的“默认配置”先烧录一次，听一下板级原厂默认的plate reverb效果，作为后续改动效果的参照基准。
3.2 评估芯片资源：plate reverb的RAM和MIPS开销
这个很多人会忽略，但我觉得恰恰是plate reverb和简单echo最本质的区别。一个plate reverb算法往往包含多个并联的梳状滤波器加上多个串联的全通滤波器，每个滤波器都是一条延迟线，延迟线的长度又由采样率决定。
举个例子，48kHz采样率下，实现一个2秒左右的plate混响尾巴，仅延迟线内存就需要数百KB级别的缓冲。这对杰理入门级蓝牙芯片来说不是小数字。中高端芯片问题不大，但低端芯片开双模（音乐模式+语音模式）同时启用plate reverb，内存很容易爆。
所以在改参数之前，先在工程配置里确认两件事：
- 当前芯片的RAM剩余空间是否满足算法实例的要求。一般音效库会提供类似
audio_effect_get_mem_size()的接口，没有的话就看链接map文件里.bss段增量。 - 处理器的负载是否足够。如果板子同时跑着降噪、EQ、DRC，再加上plate reverb，可能出现DSP处理不过来导致的卡顿。
如果资源紧张，有两条路：降低混响时间，减少延迟线长度；或者只在音乐模式下启用plate reverb，语音模式继续用轻量级回声。我实际项目中就选择了后者，效果完全够用。
3.3 最小可复现工程：先跑通原厂默认效果
动手改参数前，强烈建议先建一个最小可复现工程。我的做法是：复制一份原始工程，把蓝牙相关功能全部用默认设置，只保留音频播放链路，用一个定频音源反复播放同一段人声素材，先把原厂默认的plate reverb效果跑通。
这一步有两个目的。第一是排除变量：如果连原厂默认效果都出不来，那问题不在参数，而在开关没打开、宏没配置对、或者音效库没链接进去。第二是建立听感基准：调音最怕没有参照，原厂效果就是你的“零刻度”，后面每次改参数都跟它对比，能清晰判断改的方向对不对。
调试环境我用的是官方开发板加一个普通有源音箱，信号链路上不经过蓝牙传输，直接接SDK里的音频测试模式，避免蓝牙编解码带来的不确定性。
4. 核心参数逐项拆解与修改落地
plate reverb听起来高深，但落到杰理这套SDK里，你能控制的参数其实就那么几个。搞清楚每个参数的含义和调整方向，就能自如地控制最终听感。
4.1 预延迟：让声音“分开”的第一道开关
预延迟（pre-delay）指的是直达声和混响声之间的时间间隔。它本身不改变混响尾巴的形状，但决定了人耳能否把干声和混响区分开。
预延迟设置为0时，混响和干声同时到达，会让人觉得人声被糊住了；加大预延迟，比如20ms到40ms，干声先到，混响随后展开，声音就“透”了。
代码里预延迟的单位一般是毫秒，也有的是直接给延迟线采样点个数，换算关系是：
延迟采样点数 = 预延迟(ms) * 采样率(Hz) / 1000实际调的时候，人声建议从15ms到30ms开始试；乐器类可以从30ms到60ms。预延迟不是越大越好，超过60ms后，混响听起来会和干声脱节，像两个声音叠加而不是一个声音在空间里自然衰减。
4.2 混响时间与衰减系数：决定空间感大小的关键
混响时间通常定义为声压级衰减60dB所需的时间，简称RT60。plate reverb的RT60主要由衰减系数（decay）控制。系数越接近1，尾巴越长；越接近0，尾巴越短。
在杰理新版本里，衰减系数往往是定点数表示，范围从0到32767，对应浮点数的0到1。比如：
目标RT60下期望的衰减系数 = 0.75 -> 定点值 = 0.75 * 32767 ≈ 24576 (0x6000)注意，直接把0.75当作整数75填进去，是新手最容易犯的错，结果就是混响尾巴几乎只剩干声或者彻底消散。后面专门讲坑的时候我会再强调。
不同播放场景的建议起始值：
| 场景 | RT60建议范围 | 听感说明 |
|---|---|---|
| 蓝牙便携音箱 | 0.8s - 1.5s | 空间感明显但不拖沓 |
| 车载音响 | 1.0s - 1.8s | 让声音铺开，掩盖车内噪声 |
| 户外派对音箱 | 1.2s - 2.0s | 大空间感，适合人声和电音 |
| 语音通话/提示音 | 0.2s - 0.5s | 只加“润色”，不能影响清晰度 |
4.3 扩散度和阻尼：从“金属味”到“温暖感”
扩散度对应全通滤波器的反馈深度，控制的是混响尾巴中反射声的密集程度和音染。扩散度太低，会听到单个反射声的“颗粒感”；太高，尾巴会变得极其平滑，缺少灵动。
阻尼参数控制的是高频衰减速度。阻尼小，高频反射多，混响尾巴亮、有金属味；阻尼大，高频被吸收得快，尾巴变暗、变温暖。
这两个参数配合起来，是plate reverb调音的核心乐趣。想要亮泽感，阻尼值降低一点，扩散度保持在中间偏上；想要暗调氛围，阻尼加大，扩散度也加大，听感上就像隔了一层天鹅绒。
在我调的模拟项目X里，客户既要“亮”又不希望“金属味刺耳”，最终落在高频阻尼0.4左右、扩散度0.6左右的组合，人声会有一层光泽，但不会像老式录音棚那样“嘶嘶”地冒尖。
4.4 干湿比与高低切：混响是否贴脸的关键
干湿比就是混响效果声和原始干声的混合比例。旧版SDK里，经常看到直接给一个“混响深度”或者“混响音量”的百分比；新版本里分得更细，有wet_ratio和dry_ratio两个独立字段，甚至有的版本直接给湿声增益（wet_gain），单位是dB。
干湿比的调整思路不是平均分配，而是“先定干声，再补湿声”。我通常先把湿声关到0，找到一个舒适的主音音量；然后慢慢加湿声，直到空间感出现但人声定位还在正中间。如果湿声加得太猛，人声会向后漂，唇齿音发虚。
高低切方面，大部分plate reverb算法内部自带高通和低通滤波器，用于限制混响尾巴的频率范围。高通建议在80Hz到200Hz之间，把低频混响去掉，防止低音浑浊；低通建议在8kHz到12kHz之间，防止高频混响叠出来刺耳的“嘶声”。尤其蓝牙音箱本身高音单元小，8kHz以上的混响过多了，整体声音反而容易发毛。
4.5 新版本参数表实例：从Q格式换算到实际听感
下面给一份我实际调过的参数表，作为起步参考。不同SDK、不同采样率下数值会有差异，但换算思路是通用的。假设采样率48kHz，音效类型为plate reverb：
/* 预延迟20ms -> 20 * 48000 / 1000 = 960 采样点 */ #define PRE_DELAY_SAMPLES 960 /* 衰减系数0.78 -> 0.78 * 32767 = 25558 → 0x63D6 */ #define PLATE_DECAY 0x63D6 /* 扩散度0.55 -> 0.55 * 32767 = 18022 → 0x4666 */ #define PLATE_DIFFUSION 0x4666 /* 高频阻尼0.45 -> 0.45 * 32767 = 14745 → 0x3999 */ #define PLATE_DAMPING 0x3999 /* 湿声增益：-6dB，对应线性幅度约0.5 -> 0x4000 */ #define PLATE_WET_GAIN 0x4000实际修改时，可能还要连带改hp_cutoff和lp_cutoff。高通截止频率100Hz在48kHz采样率下，归一化频率为100/24000 = 0.00417，如果SDK用12位定点表示归一化频率，就是0.00417 * 4096 ≈ 17，即0x0011。这些数值通常都在工具界面里直接填，代码里看到的已经是工具生成的结果，理解换算逻辑有助于排查问题。
5. 编译烧录与在线调参：让修改真正生效
参数改完了，还得让它跑在板子上。这一步看着简单，但新版本SDK有几个关键点容易出问题。
5.1 编译关键点：避免链接到旧音效库
新版本SDK把音效算法封装成静态库后，最怕的就是工程里存在多个版本的音效库，编译链接时把旧的链接进去。我在一个工程里就见过lib目录下同时存在audio_effect_lib.a和audio_effect_lib_old.a，makefile里通配符把两个都搜进来了，链接顺序不确定，最后板子跑出来的混响效果根本不对。
解决办法是检查makefile或CMakeLists里的库搜索路径，明确指定用哪个.a。如果发现多个音效库文件，建议把不用的删掉或改名，不要抱有侥幸心理。
5.2 烧录与配置区说明：改了参数为什么没生效
烧录之后听不出变化，是最让人抓狂的情况。新版本SDK里，有个判断逻辑常常把人绕进去：音效参数可能不在固件里，而是放在Flash单独配置区。如果开发板上电时读取的配置区数据覆盖了代码里的默认参数，那么你改代码里的数组是没用的。
排查思路是这样：
- 确认代码里有没有“从Flash加载音效配置”的宏开关，有就暂时关掉。
- 查看烧录工具的配置区擦除选项，把音效配置区一并擦掉，让固件用代码里的默认参数跑一遍。
- 如果擦掉之后plate reverb效果就正常了，说明问题确实出在Flash配置覆盖。
我后来在项目里统一采用了“开发阶段关掉Flash配置覆盖，量产阶段用工具导入配置”的方式，两边职责清楚，调试效率高不少。
5.3 在线联调：利用调试工具边听边改
杰理的SDK自带调试接口和上位机工具，可以实现音频效果的在线实时调参。开发板上电后，调试工具通过串口或USB连接，修改参数并即时下发到板子，不用反复编译烧录。
这个环节我的建议是：先把一组你比较有信心的参数存成一组预设，然后边播放测试曲目边切预设对比。测试曲目建议选三种：纯人声说话、有人声的流行乐、器乐为主的纯音乐。不要只用一首歌调音，否则换歌之后效果可能完全翻车。
另外，在线调节时，湿声增益这类参数可以飞梭式地连续拉，感受参数从0到目标值的渐变，特别容易找到临界点。比听感更直观的方法是看DSP的输出电平表：如果开启混响后信号总是顶到0dBFS，说明湿声增益加得太多，需要回调。
6. 新版plate reverb最容易踩的四个坑
最后这部分，我把实际调试过程中踩过的坑集中梳理一遍。这些坑每个都很隐蔽，不遇到时根本想不到，遇到了能折腾你好几天。
6.1 坑一：定点数当整数用，声音直接破音
新版本SDK参数表大量使用定点数，但不同参数定点格式不一样。衰减系数、扩散度、阻尼这类“归一化系数”一般是Q15格式，范围0到32767；增益类可能是Q12格式，范围0到4095；而预延迟、截止频率可能是纯整数采样点。
最典型的问题：想把衰减系数设成0.75，直接在工具或代码里填了75。结果算法按0.0015的衰减来算，混响尾巴几乎全被吸掉，或者因为归一化后的数值超出范围导致溢出。我在处理模拟项目X时，就曾经因为把0x6000（24576）写成了6000，听感上高频全糊掉了，还以为是阻尼参数填错了。
调试这种问题的办法是，拿到参数表后先按Q格式换算回浮点数，确认每个值都在合理范围内。可以写个小脚本，把数组里的值全部按不同Q格式解析出来，一目了然。
6.2 坑二：改采样率后混响时间漂移
同一个参数表，在44.1kHz和48kHz采样率下，实际听感完全不同。因为延迟线的长度是按采样点算的，采样率变了，延迟时间就变了。比如预延迟960个采样点在48kHz下是20ms，在44.1kHz下就变成约21.8ms，这个差异不大；但衰减系数导致的RT60漂移会更明显，因为整个反馈链路的时长基准都变了。
解决办法有两个：一是不同采样率各建一套参数表，播放时切换；二是做采样率自适应换算，把时间类的参数按实际采样率缩放后再喂给算法。老版本SDK可能没有这个机制，新版本一般预留了接口。我建议直接按采样率分别调，虽然工作量大一点，但稳。
6.3 坑三：内存不够导致转圈或复位
plate reverb对延迟线内存的消耗，前面已经说过。低端芯片上，如果你把混响时间调得很长，又同时打开立体声plate reverb，内存很可能会不够。表现症状不是直接死机，而是一播放音乐就转圈，或者在模式切换瞬间复位。
内存问题很难在调参阶段发现，我在开发板上用中高端芯片调得好好的参数，移植到低端芯片上就翻车了。验证方法是看编译后map文件里音效模块的RAM占用，再对照芯片的剩余RAM空间。如果紧张，优先缩小立体声配置，改成单声道plate reverb，然后缩短混响时间，这两招立竿见影。
6.4 坑四：先DRC后混响，湿声被压回干声
这个问题最隐蔽，听感上“加了混响等于没加”。原因不在混响本身，而在于DSP链路里DRC在混响前面。
我实际遇到的场景是：客户抱怨大音量下plate reverb失效，低音量下还正常。排查了一圈，发现DRC的压缩阈值设得比较低，湿声增益又开得大，混响尾巴信号在DRC之后被严重压缩，动态被压平了。
解决思路有两个：把混响移动到DRC之前处理，让压缩器对混响后的信号统一控制；或者调低DRC压缩比和阈值，给混响尾巴留出余量。但要注意，移动信号链路上处理顺序不只是改代码，算法库的实例建立顺序、缓冲区数量都要跟着调，比较费事。如果DSP框架允许，我更推荐后一种：降低湿声增益，实际上混响场景很少需要湿声超过干声的70%。
最后分享一个我自己的调音手法，不一定适合所有产品，但帮我在很多项目里省了时间：先用一个非常突出的参数组合把plate reverb“调过头”，比如混响时间拉满、湿声拉到最大，然后一边听一边把参数往回收，直到空间感和清晰度刚好平衡的位置。这个过程让你对每个参数的极限影响有直观感知，比从零开始一点点加要快得多。调完之后，记得把不同采样率、不同模式下的参数全部过一遍，尤其注意切歌、切模式、切音量时有没有杂音或定位漂移。音效这活儿，最终是靠耳朵验收的，工具和参数表只能帮你把路铺平。
