循环缓冲区处理音频流需固定容量、指针回绕和线程安全，以保障帧对齐、实时性与低延迟；核心是数组+读写索引，按帧批量操作，防范溢出并优化内存对齐。
用数组实现循环缓冲区处理音频流，关键在于固定容量、指针回绕和线程安全读写，不是简单存取，而是要匹配音频数据的连续性、实时性和低延迟要求。
核心结构设计：固定数组 + 读写索引
音频流是连续帧组成的字节流（如 16-bit stereo PCM，每帧4字节），必须用固定大小数组避免动态分配开销。定义两个整型索引：
-
write_index：指向下一个可写入位置，每次写入后递增，越界时用
write_index = (write_index + 1) % capacity回绕 - read_index：指向下一个可读取位置，每次读出后同样取模回绕
- 缓冲区为空的判断条件是
read_index == write_index - 缓冲区为满时，常见做法是预留一个空位：
(write_index + 1) % capacity == read_index，避免空/满状态歧义
音频流适配要点：帧对齐与批量操作
音频数据不能按单字节读写，必须以“帧”为单位操作，否则会破坏声道交错结构（如 LRLR…）。例如：
- 采样率 48kHz、16-bit、双声道 → 每帧 = 4 字节，每秒 48000 帧
- 申请缓冲区容量建议为帧数倍数，如 2048 帧 → 数组长度 = 2048 × 4 = 8192 字节
- 写入函数接收
int16_t* pcm_data和帧数n_frames，内部按字节偏移计算起始位置并 memcpy - 读取同理，返回可用帧数而非字节数，便于上层做等长音频块处理（如送入 FFmpeg 编码器或 AAudio 播放）
实战中必须处理的三个问题
在嵌入式（ESP32）、Android 音频或 PC 端实时处理中，仅实现基础环形逻辑远远不够：
-
生产者-消费者竞争：音频采集线程（生产者）和处理线程（消费者）同时访问同一缓冲区，必须加锁（如 pthread_mutex）或用原子操作保护索引更新；更优方案是分离读写路径，如 Android 中用
AAudioStream的回调配合双缓冲区 - 下溢与上溢防护：采集过快导致覆盖未读数据（上溢），或处理过慢导致读取空缓冲区（下溢）。需在写入前检查剩余空间，在读取前检查有效数据量，并记录溢出次数用于调试
-
内存对齐与零拷贝优化：使用
aligned_alloc或posix_memalign分配缓存，确保地址对齐到 64 字节；若硬件支持（如 ESP32 I2S DMA），可让 DMA 直接写入环形缓冲区物理地址，跳过中间拷贝
一个轻量 C++ 示例片段（无锁简化版）
适用于单生产者单消费者场景（如 I2S 采集 + 主循环处理）：
class AudioRingBuffer {public:
AudioRingBuffer(size_t frame_count, size_t bytes_per_frame)
: capacity_(frame_count * bytes_per_frame),
data_(new uint8_t[capacity_]),
write_idx_(0), read_idx_(0) {}
size_t available_write() const {
return (read_idx_
: read_idx_ - write_idx_ - 1;
}
void write(const void* src, size_t bytes) {
size_t avail = available_write();
if (bytes > avail) bytes = avail;
size_t tail_space = capacity_ - write_idx_;
if (bytes
memcpy(data_ + write_idx_, src, bytes);
write_idx_ = (write_idx_ + bytes) % capacity_;
} else {
memcpy(data_ + write_idx_, src, tail_space);
memcpy(data_, static_cast
write_idx_ = bytes - tail_space;
}
}
// 对应 read() 实现类似，略
private:
const size_t capacity_;
uint8_t* const data_;
size_t write_idx_, read_idx_;
};
