4. Codec基础
Buffer管理，说白了就是音频数据在算法模块和Codec之间怎么流转、怎么存、怎么不丢。我刚开始做联调时，觉得这玩意儿不就是个队列嘛，结果被丢帧、卡顿、爆音轮番教育。后来才明白——Buffer管不好，算法再牛也白搭。
这一章，咱们就聊聊环形缓冲区怎么设计、多线程下怎么同步、丢帧和重采样怎么处理。嗯，都是实战里踩过的坑。
4.1 环形缓冲区设计
环形缓冲区（Ring Buffer）是音频处理里最常用的数据结构。为什么用环形？说白了就是避免频繁的内存分配和释放。你想想看，音频数据是源源不断的流，如果用链表或者动态数组，每次读写都malloc/free，延迟和碎片都受不了。
我个人的习惯是，在联调初期就固定好缓冲区大小。大小怎么定？得看三个因素：
- 最大延迟容忍度：比如通话场景，端到端延迟不能超过200ms，那缓冲区就不能太大。
- Codec的帧长：比如AAC每帧1024个采样，那缓冲区最好是1024的整数倍。
- 算法处理时间：如果算法处理一帧需要5ms，那缓冲区至少得能扛住一次处理抖动。
下面是我常用的环形缓冲区结构定义：
typedef struct {
int16_t *buffer; // 数据存储区
int size; // 缓冲区总大小（采样点数）
int write_pos; // 写指针
int read_pos; // 读指针
int count; // 当前有效数据量
pthread_mutex_t lock; // 互斥锁
} ring_buffer_t;
这里有个关键点：count字段。很多人只用读写指针判断空满，但多线程下指针的加减不是原子的，容易出问题。我建议显式维护一个count，配合原子操作或者锁来保证一致性。
核心原则：环形缓冲区的读写指针永远只在一个方向上移动。写指针追读指针，读指针追写指针。一旦追上，要么阻塞，要么覆盖——取决于你的策略。
读写操作的伪代码大概是这样：
// 写操作
int ring_buffer_write(ring_buffer_t *rb, int16_t *data, int len) {
pthread_mutex_lock(&rb->lock);
if (rb->count + len > rb->size) {
// 缓冲区满了，处理溢出
pthread_mutex_unlock(&rb->lock);
return -1;
}
int end = rb->size - rb->write_pos;
if (len <= end) {
memcpy(rb->buffer + rb->write_pos, data, len * sizeof(int16_t));
} else {
memcpy(rb->buffer + rb->write_pos, data, end * sizeof(int16_t));
memcpy(rb->buffer, data + end, (len - end) * sizeof(int16_t));
}
rb->write_pos = (rb->write_pos + len) % rb->size;
rb->count += len;
pthread_mutex_unlock(&rb->lock);
return 0;
}
注意那个环形回绕的处理——分两段拷贝。我见过有人直接用memcpy从write_pos一直拷到末尾，不管越界，结果就是踩内存。嗯，这个坑我踩过。
4.2 多线程下的数据同步
音频联调里，典型的多线程场景是这样的：
- 采集线程：从麦克风或Codec读数据，写入环形缓冲区。
- 处理线程：从缓冲区读数据，做算法处理（降噪、AGC、编解码等）。
- 播放线程：把处理后的数据送Codec播放。
这三个线程跑在不同的优先级上，采集和播放通常是硬实时，处理线程可以稍微松一点。但问题来了——怎么保证数据不被撕碎？
我建议用无锁队列 + 内存屏障的方案。为什么？因为锁的开销在音频这种高频率场景下不可忽视。你想想看，每5ms就要读写一次，如果每次都用pthread_mutex_lock，上下文切换和等待时间加起来，延迟就上去了。
无锁队列的核心思路是：
- 写线程只修改写指针，读线程只修改读指针。
- 用
__sync_bool_compare_and_swap或者C11的atomic_compare_exchange_strong来保证指针更新的原子性。 - 用
__sync_synchronize或者atomic_thread_fence保证内存可见性。
小技巧：如果实在不想搞无锁，可以用双缓冲（Double Buffer）方案。一个缓冲区给采集线程写，另一个给处理线程读，写完交换指针。代价是多一倍的存储空间，但实现简单，不容易出bug。
我曾经在一个项目里用过std::atomic<int>来管理读写指针，配合memory_order_acquire/release，效果还不错。但要注意——单生产者单消费者场景下无锁才安全。如果有多个写线程，还是老老实实加锁吧。
4.3 丢帧处理
丢帧，是联调里最头疼的问题之一。原因很多：
- 采集线程被更高优先级任务抢占，没来得及读数据。
- 处理线程计算量太大，一帧没处理完下一帧就来了。
- Codec驱动底层有bug，偶尔漏掉一个中断。
丢帧的直接后果就是——音频断断续续，或者出现“咔哒”声。怎么处理？
我常用的策略有三种：
| 策略 | 做法 | 适用场景 |
|---|---|---|
| 静音填充 | 丢掉的帧用0填充 | 丢帧率很低（<0.1%），且人耳不敏感 |
| 重复前一帧 | 用上一帧的数据填补空缺 | 语音信号，短时平稳 |
| PLC（丢包隐藏） | 用预测模型生成丢失的音频 | Codec自带PLC，或者有计算资源 |
我个人最常用的是重复前一帧。为什么？因为语音信号在几十毫秒内变化不大，重复一帧人耳基本听不出来。但要注意——如果是音乐或者瞬态信号（比如拍手声），重复前一帧反而会产生奇怪的“回声”效果。这时候就得用PLC了。
避坑指南：我曾经在一个VoIP项目里，丢帧后直接静音填充，结果用户反馈“声音像卡带了一样”。后来改成重复前一帧，配合淡入淡出（交叉衰减），问题就解决了。交叉衰减的长度我建议取5~10ms，太长会有拖尾感，太短会有咔哒声。
4.4 重采样处理
重采样，说白了就是把音频从一个采样率转到另一个采样率。联调里为什么需要重采样？
- Codec输出是48kHz，算法处理需要16kHz。
- 采集设备是44.1kHz，Codec只支持48kHz。
- 不同模块的帧长不一致，需要重采样来对齐。
重采样的核心是插值。最简单的线性插值，质量差但速度快；复杂的Sinc插值，质量好但计算量大。我一般用多相滤波器（Polyphase Filter），在质量和效率之间取个平衡。
多相滤波器的思路是：预先计算好一组滤波器系数，每个系数对应一个相位偏移。重采样时，根据输入输出采样点的比例，选择对应的滤波器做卷积。这样做的好处是——计算量固定，不随采样率变化而剧烈波动。
下面是一个简单的重采样流程：
// 重采样：从src_rate转到dst_rate
int resample(int16_t *input, int input_len,
int16_t *output, int *output_len,
int src_rate, int dst_rate) {
double ratio = (double)dst_rate / src_rate;
int out_len = (int)(input_len * ratio);
for (int i = 0; i < out_len; i++) {
double src_pos = i / ratio; // 输入中的对应位置
int src_idx = (int)src_pos;
double frac = src_pos - src_idx;
// 线性插值
output[i] = (int16_t)((1 - frac) * input[src_idx] +
frac * input[src_idx + 1]);
}
*output_len = out_len;
return 0;
}
这个例子用的是线性插值，简单但会有高频失真。实际项目中，我建议用三次样条插值或者带通滤波+抽取/插值。嗯，具体用哪种，得看你的音质要求和CPU预算。
关键点：重采样前后，一定要做抗混叠滤波。否则，高频分量会折叠到低频，产生“镜像频率”噪声。我见过有人直接线性插值，结果高频嘶嘶声全进来了——那就是没做抗混叠。
4.5 知识体系总览
下面这张图，把Buffer管理的核心逻辑串起来了：
从图上能看出来，环形缓冲区是核心，它连接了多线程同步、丢帧处理和重采样三个方向。每个方向又有自己的子策略。实际联调时，你得根据场景组合使用——比如采集线程用无锁队列写缓冲区，处理线程读出来发现丢帧了，用重复前一帧填补，然后重采样到Codec需要的采样率。
嗯，这一套流程走通了，Buffer管理这块基本就稳了。