混音前必须统一采样率和声道数，用重采样与声道转换预处理；多线程混音需用std::thread+原子/分块锁保障线程安全；时序依赖std::chrono::steady_clock；最终归一化由主线程单次执行。
混音前必须对齐采样率和声道数
不同音频源的采样率（如 44100、48000）或声道数（单声道/立体声）不一致时，直接相加会导致爆音、失真或越界访问。C++ 中没有运行时类型强制对齐机制，必须在混音前统一预处理。
实操建议：
- 用
std::vector<float></float>统一存储重采样后的样本（避免整型溢出，且便于归一化） - 推荐使用
libresample或libsamplerate做高质量重采样；若追求轻量，可用线性插值快速对齐44100↔48000（误差可接受） - 声道数不同时，立体声转单声道用
(left + right) * 0.5f；单声道转立体声则左右通道复制 - 务必检查重采样后缓冲区长度是否一致——多线程下若某路提前结束而未填充静音，混音数组索引会错位
std::thread + std::vector<:thread> 是最可控的并发模型
用 std::async 容易因默认启动策略（std::launch::deferred）导致“看似并发实则串行”，而 std::jthread（C++20）虽自动 join，但调试时难以控制生命周期。实际混音场景中，每路音频帧处理时间波动大，需显式管理线程启停与异常传播。
实操建议：
- 为每路音频分配独立
std::thread，传入 lambda 捕获该路的输入缓冲区、重采样器、输出混音缓冲区指针 - 用
std::atomic<bool></bool>控制运行状态，避免join()阻塞时无法响应停止信号 - 每个线程内捕获
std::exception_ptr并写入共享队列，主线程定期检查——音频线程崩溃不抛异常到主线程，静默失败比 crash 更难排查 - 避免在线程中 new/delete 频繁小内存块；改用预分配的
std::vector<float></float>池 + 索引复用
混音累加必须用原子浮点操作或分段锁
多个线程同时对同一块混音缓冲区（如 output_buffer[i] += sample）做非原子写入，会产生竞态：两个线程读到相同旧值，各自加后写回，其中一次结果丢失。x86 上 float 的 += 不是原子指令，std::atomic<float></float> 在 C++20 前不被广泛支持（GCC 11+ 才稳定），硬上会触发锁模拟，性能暴跌。
实操建议：
- 将混音缓冲区分成固定大小的块（如每块
1024样本），每路线程只负责一个块——需提前按路数和缓冲区长度做静态划分，避免临界区 - 若必须全局混音，用
std::mutex保护整个累加循环（不要锁单个样本！），粒度控制在每次处理64~256个样本后 unlock/relock，平衡吞吐与延迟 - 禁用编译器自动向量化（
-fno-tree-vectorize）——SIMD 指令在锁区内可能引发未定义行为 - 最终归一化（防止溢出）必须放在所有线程完成之后，由主线程单次执行：
for (auto& s : output_buffer) s = std::clamp(s, -1.0f, 1.0f)
std::chrono::steady_clock 是唯一可靠的音频时序基准
混音不是纯计算任务，它强依赖时间精度。用 std::time(nullptr) 或 gettimeofday() 会受系统时钟跳变影响；std::chrono::system_clock 可能被 NTP 调整；只有 std::chrono::steady_clock 单调递增，适合驱动音频帧调度。
实操建议：
- 以主音频设备的硬件周期（如
10ms帧）为基准，用steady_clock::now()计算每路音频应处理的样本数，而非固定循环次数 - 各路线程不应自己 sleep——用条件变量等待主线程广播“下一帧开始”信号，避免因线程调度偏差累积时延
- 记录每路的实际处理耗时（
steady_clock::duration），若连续 3 帧超8ms（对48kHz即 384 个样本），主动丢弃该路当前帧，防止拖垮整体 pipeline - 注意：Windows 上
steady_clock分辨率可能仅15ms，需调用timeBeginPeriod(1)提升精度（记得配对timeEndPeriod(1)）
混音线程间真正的难点不在加法本身，而在样本时间戳对齐、缓冲区生命周期管理和错误静默传播——这些地方一旦出问题，声音只是“听起来不对”，日志里却找不到报错。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
