PortAudio回调和JUCE processBlock中严禁耗时操作，须预分配内存、用无锁环形缓冲区、算法移至工作线程；滤波器需prepareToPlay预热；时间同步应基于样本计数或宿主提供的时间戳。
PortAudio 实时音频回调里不能做耗时操作
PortAudio 的 PaStreamCallback 函数是在高优先级音频线程里被反复调用的，任何阻塞、内存分配、锁竞争、STL 容器构造（比如 std::vector::push_back）、甚至 std::cout 都可能引发 xrun（缓冲区欠载），表现为爆音、卡顿或直接崩溃。
实操建议：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 回调函数内只做最简数据搬运：把输入缓冲区拷进你预分配好的环形缓冲区（如
juce::AudioBuffer或自定义无锁 ring buffer），再从另一端取处理结果写回输出缓冲区 - 所有算法处理（FFT、滤波、插值）必须放在独立的工作线程中，用原子标志或信号量通知处理就绪
- 避免在回调里 new/delete —— 启动时一次性分配好所有音频缓冲和中间数组，用
std::array或裸指针 +malloc（后者更可控） - 调试时用
Pa_Sleep(1)模拟延迟，立刻能复现 xrun，比等真实卡顿快得多
JUCE 的 AudioProcessor::processBlock 必须严格守时
JUCE 把音频处理抽象成 processBlock，但它底层仍依赖 PortAudio / CoreAudio / WASAPI 等，所以时间约束没放松半点。常见错误是误以为“JUCE 封装了实时性”，结果在里头调 std::sqrt 做每样本计算、或用 juce::IIRFilter::processSamples 但没预热滤波器状态，导致首帧输出全零或溢出。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 所有 IIR/FIR 滤波器必须在
prepareToPlay()中用静音块预跑至少 1024 样本，让内部状态收敛 - 避免在
processBlock中调用任何带分支预测失败风险的函数 —— 比如std::abs(x)对负零行为不一致，改用x - 若需动态参数（如旋钮值），必须用平滑器（
juce::SmoothedValue）在 audio thread 外更新，在processBlock中只读取当前平滑值 - 开启 JUCE 的调试断言：
JUCE_ENABLE_AUDIO_DEBUGGING=1，它会在超时前几毫秒触发断点
Windows 上 WASAPI 共享模式 vs 独占模式延迟差异极大
PortAudio 在 Windows 默认走 WASAPI 共享模式，缓冲区最小只能设到 32ms；切独占模式后可压到 2–5ms，但代价是其他程序放不了音 —— 这不是 bug，是 Windows 音频栈设计使然。很多人测出高延迟后反复调 Pa_OpenStream 的 framesPerBuffer，却忘了看 PaWasapiStreamInfo 的 flags 字段。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 初始化 PortAudio 流前，显式设置
PaWasapiStreamInfo并传入paWinWasapiExclusive标志 - JUCE 用户需在
AudioDeviceManager::AudioDeviceSetup中把useDefaultInput/Output设为 false，并手动选 “WASAPI (exclusive)” 设备 - 独占模式下系统音量控制失效，务必在 UI 提供自己的增益调节（乘以 float 增益系数，别碰
ISimpleAudioVolume） - 测试时用
Pa_GetStreamInfo()检查返回的inputLatency/outputLatency，别信设备管理器里写的“延迟：10ms”
跨平台音频时间戳对齐很脆弱
PortAudio 不提供可靠的时间戳，Pa_GetStreamTime() 返回的是流启动后的单调秒数，但不同设备、不同 API（ALSA vs CoreAudio）的精度和偏移都不同；JUCE 的 getPlayHead()->getPosition() 在离线渲染时才准，在实时流里只是估算。想做精确节拍同步或 MIDI 对齐，光靠这个会漂移。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 不要用
Pa_GetStreamTime()做相位计算 —— 改用样本计数：在回调开头累加frameCount，再除以采样率转为秒，误差稳定在 ±1 sample - JUCE 中启用
AudioPlayHead::CurrentPositionInfo::timeInSamples，它由 host（如 DAW）提供，比本地推算靠谱得多；standalone app 则必须自己维护一个std::atomic<int64_t></int64_t>计数器 - 如果要用 wall-clock 时间（比如记录录音起始时刻），得在第一个非零音频块到来时，用
std::chrono::high_resolution_clock::now()打点，之后全靠样本数推算 - 注意：某些 USB 音频设备会悄悄重采样，导致样本计数和实际物理时间不一致 —— 用
arecord -l（Linux）或Audio MIDI Setup（macOS）确认设备是否报告了正确采样率
