音频缓冲区指针操作必须明确数据类型、字节对齐与声道布局：16-bit PCM用int16_t，避免void直接运算；需区分interleaved/planar格式；强制const限定输入缓冲区；缓冲区内存由API管理，禁止delete/free；初始化预分配中间缓冲区。
指针直接操作音频缓冲区时，必须明确数据类型和字节对齐
音频流数据本质是连续的原始字节序列，C++ 中用指针处理的核心前提是：不能用 void* 长期持有或计算偏移，必须强制转换为带尺寸信息的类型指针。比如 16-bit PCM 数据应统一用 int16_t*，而非 char* 或 unsigned char*——否则 ptr + 1 会错位 1 字节而非 2 字节，导致采样点错乱。
常见错误现象：memcpy(dst, src, len) 后播放杂音，往往是因为 src 是 int16_t* 但 len 却传了“样本数”而非“字节数”，或者反向混淆。
- 读取 44.1kHz、立体声、16-bit PCM 流时，每帧 4 字节（左+右各 16 位），指针步进单位必须是
int16_t*，每次加 2 才跳过一帧 - 若底层 API（如 PortAudio、SDL2）返回
void* buffer，立刻转成目标类型：auto samples = static_cast(buffer) - 避免跨平台陷阱：Windows 的
WAVE_FORMAT_PCM默认小端，ARM/Linux 通常也是小端，但嵌入式音频芯片可能要求大端——此时不能只改指针类型，需用htons()或位运算翻转
用 const 指针和引用限定所有权，防止误写音频缓冲区
多数音频回调函数（如 PortAudio 的 paStreamCallback）传入的输出缓冲区是可写的，输入缓冲区是只读的。C++ 指针若不加 const 限定，极易在处理逻辑中意外修改输入流，造成回声、爆音或崩溃。
使用场景：在回调中同时读输入、写输出，且需做实时混音或滤波。
- 正确签名示例：
int audioCallback(const void* input, void* output, unsigned long frameCount, ...)→ 立即转为：const float* in = static_cast和(input) float* out = static_cast(output) - 禁止对
in做任何赋值或 ++/-- 操作；若需缓存历史样本，必须拷贝到自有数组，而非直接保存in指针 - 当封装音频处理类时，成员变量存储缓冲区指针应带
const修饰，例如：const int16_t* m_inputBuffer;，编译器会在误写时报错
避免野指针：音频缓冲区生命周期由 API 控制，不是 new 出来的就要自己 delete
绝大多数音频库（ALSA、Core Audio、WASAPI、OpenSL ES）分配的缓冲区内存由其内部管理，回调中拿到的指针仅在本次回调周期内有效。用 new 或 malloc 自行分配缓冲区反而容易引发内存泄漏或竞争——尤其在多线程音频引擎中。
性能影响：频繁 new/delete 在音频主线程中会造成不可预测的延迟毛刺（glitch），实测在 48kHz/64-sample 块大小下，一次 new 可能引入 >1ms 延迟。
- PortAudio 回调中绝对不要对
input/output指针调用delete或free - 如需中间处理缓冲区（如 FFT 输入），应在初始化阶段一次性
new并复用，或用std::vector管理（确保.data()返回的指针稳定） - 使用 RAII 封装：例如
AudioBufferPool类在构造时预分配一组std::vector，回调中通过索引取用，避免运行时分配
指针算术与声道布局强相关，别假设“左声道总在前”
音频数据排列方式（interleaved vs. planar）直接影响指针怎么走。C++ 指针算术本身不理解声道概念，全靠程序员按格式解释字节流。Interleaved（交错）是主流，但 Web Audio、某些 DSP 库倾向 planar（平面），混用会导致左右声道互换或静音。
错误现象：立体声播放变成单声道，或左右颠倒；用 Audacity 查看波形发现两轨完全相同或镜像。
- Interleaved（如 WAV）：
[L0, R0, L1, R1, L2, R2, ...]→int16_t* p指向 L0，p[0]是左，p[1]是右，p[i*2]是第 i 帧左声道 - Planar（如 FFmpeg AVFrame）：左声道所有样本连续存放，再放右声道 → 需两个指针：
int16_t* left = ...; int16_t* right = left + sampleCount; - 永远以 API 文档为准：PortAudio 默认 interleaved；JUCE 的
AudioBuffer内部是 planar，但getReadPointer(0)返回的是第 0 声道起始地址
音频流指针操作的复杂点不在语法，而在对“内存布局 + 时间约束 + API 所有权”的三重同步。一个没对齐的 int16_t* 偏移，或一次越界读取，都可能让整个流从某帧开始持续破音——而这种问题往往在压力测试或特定设备上才暴露。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
