1. 问题现象与背景分析
最近在调试杰理AC79系列蓝牙芯片的录音功能时，遇到一个棘手问题：当开启混合录音模式并输出WAV格式文件时，录制的音频会出现明显的卡顿现象。具体表现为音频播放时每隔几秒就会出现短暂中断，类似"咔嗒"声的异常音效，严重影响录音质量。
这种情况在以下特定场景下复现率极高：
- 使用AC79系列芯片的蓝牙耳机产品
- 同时开启环境音和蓝牙音频的混合录制
- 输出格式设置为16bit/16kHz的WAV文件
- 持续录音时长超过30秒后开始出现
作为一款广泛应用于TWS耳机的芯片方案，杰理AC79的录音功能本是产品亮点之一。混合录音模式允许同时录制来自蓝牙传输的音频和麦克风采集的环境声，这在会议记录、外语学习等场景非常实用。但卡音问题直接影响了核心功能的用户体验。
2. 问题定位与排查过程
2.1 初步现象分析
首先通过以下步骤确认问题特征：
- 使用Audacity音频软件分析异常WAV文件
- 观察波形图发现规律性断层（约每3秒出现一次）
- 频谱分析显示断层处有高频噪声脉冲
- 正常录音文件大小应为：采样率×位深×时长，但问题文件比理论值小5-8%
2.2 关键怀疑点排查
根据现象重点排查以下方向：
内存管理问题
- 检查录音缓冲区的分配策略
- 确认双缓冲切换时的临界条件
- 监控堆内存使用情况（发现峰值占用达85%）
文件系统写入
- 测试不同SD卡速度等级（Class10卡问题依旧）
- 尝试减少单次写入块大小（从4KB调整为2KB略有改善）
- 检查文件系统缓存机制（发现未启用写入缓存）
DMA传输配置
- 核对音频DMA的传输完成中断配置
- 测量I2S时钟稳定性（发现偶发jitter）
- 检查双声道数据对齐方式（发现右声道偶有错位）
2.3 决定性证据发现
通过逻辑分析仪捕获到关键现象：
- 每次音频卡顿前，I2S_LRCK信号会出现约200us的异常跳变
- 对应时间点DMA传输计数器被异常重置
- 系统日志显示此时内存分配器正在执行GC操作
3. 根本原因解析
3.1 内存管理缺陷
杰理SDK默认配置存在以下问题：
- 音频缓冲区和文件系统缓冲共用内存池
- 未针对混合录音场景调整内存分配策略
- 内存碎片整理触发时未暂停音频采集
具体导致：
code复制正常流程：
音频采集 -> DMA传输 -> 双缓冲切换 -> 文件写入
异常流程：
音频采集 -> 内存不足触发GC -> DMA缓冲区被释放 -> 音频数据丢失 -> GC完成后重新分配缓冲区
3.2 时钟同步问题
混合录音模式下：
- 蓝牙音频使用44.1kHz时钟源
- 麦克风使用16kHz时钟源
- 系统未正确同步两个时钟域导致：
- 每3秒左右会出现采样点计算误差
- 引发DMA传输计数器重置
4. 解决方案与验证
4.1 内存优化方案
独立内存池配置
c复制// 修改memory_cfg.h
#define AUDIO_BUF_POOL_SIZE (1024*12) // 原为8KB
#define FILE_BUF_POOL_SIZE (1024*16) // 原为12KB
// 启用专用音频内存池
void audio_init() {
audio_buf = os_mem_alloc(AUDIO_BUF_POOL_SIZE);
// ...其他初始化
}
关键参数调整
- 将音频缓冲区从ping-pong双缓冲改为三缓冲
- 设置内存低水位线阈值（剩余15%时预警）
- 禁用自动GC改为手动触发
4.2 时钟同步方案
硬件层面
- 统一使用PLL2生成主时钟
- 增加时钟监控电路
软件层面
c复制// 新增时钟同步处理
void audio_clock_sync() {
static uint32_t last_bt_ts, last_mic_ts;
uint32_t curr_bt = get_bt_timestamp();
uint32_t curr_mic = get_mic_timestamp();
if(abs(curr_bt - last_bt_ts) != abs(curr_mic - last_mic_ts)) {
adjust_clock_skew((curr_bt - last_bt_ts) - (curr_mic - last_mic_ts));
}
last_bt_ts = curr_bt;
last_mic_ts = curr_mic;
}
4.3 文件系统优化
写入策略调整
- 启用写入缓存（4KB）
- 设置合理的flush间隔（每500ms）
- 采用交错写入模式：
code复制原顺序：
[蓝牙数据][麦克风数据][蓝牙数据][麦克风数据]...
优化后：
[蓝牙1+麦克1][蓝牙2+麦克2]...
5. 实测效果与参数对比
优化前后关键指标对比：
| 测试项 | 优化前 | 优化后 |
|---|---|---|
| 卡顿次数/分钟 | 18-22次 | 0次 |
| 内存峰值占用 | 85% | 68% |
| 文件大小偏差 | 5-8% | <0.1% |
| 功耗增加 | - | +2.3mA |
| 延迟 | 120±15ms | 105±5ms |
实测录音样本频谱分析显示：
- 噪声基底从-65dB降至-72dB
- 高频段（>10kHz）谐波失真改善6dB
- 左右声道同步误差<50us
6. 生产注意事项
6.1 硬件设计建议
- 为音频电路预留独立LDO供电
- 时钟线走线避免与数字信号平行
- 麦克风偏置电压需稳定在1.8V±2%
6.2 软件配置要点
ini复制# 推荐SDK配置参数
[audio]
mix_mode=1 ; 混合模式
mem_pool=2 ; 使用独立内存池
cache_size=4096 ; 文件缓存大小
clock_sync=1 ; 启用时钟同步
[debug]
audio_dump=0 ; 关闭调试dump以节省内存
log_level=1 ; 仅记录错误日志
6.3 常见问题处理
Q：升级后出现录音启动失败？
A：检查memory_cfg.h中的池大小是否匹配硬件资源
Q：小概率仍有轻微爆音？
A：尝试将I2S时钟分频系数从8调整为16
Q：长时间录音后卡顿再现？
A：确保定期调用os_mem_defrag()进行内存整理
7. 深度优化建议
对于要求更高的场景，可考虑：
动态码率调整
c复制// 根据内存压力自动调整采样率
void dynamic_adjust() {
if(os_get_free_mem() < 1024) {
set_sample_rate(8000); // 降为8kHz
} else {
set_sample_rate(16000);
}
}
混合编码方案
- 蓝牙音频保持16bit PCM
- 麦克风音频转为ADPCM
- 后期通过时间戳对齐合成
实际测试发现，采用动态调整策略可在内存紧张时保持录音连续性，虽然音质略有下降但避免了卡顿。这种方案特别适合需要超长录音的场景，比如持续8小时以上的会议记录。