MMEAPI（waveIn*）音频录制：Windows 10单次仅能添加一个缓冲区问题

问题根源 #

Windows 10之后，MMEAPI的底层实现已切换为WASAPI，和XP/2000时代的内核音频栈逻辑完全不同。旧系统里MME允许提前将多个缓冲区加入队列，由内核自动调度填充；但新版系统中，MME默认映射到WASAPI的独占模式，这种模式下严格限制待处理的缓冲区数量——通常只能同时存在一个活跃缓冲区，必须等这个缓冲区被填满（触发WIM_DATA回调）后，才能添加下一个，这就是你遇到错误码33（WAVERR_STILLPLAYING）的原因。

解决办法 #

虽然没法回到旧版的多缓冲区预加载逻辑，但只要优化回调处理，完全可以避免音频间隙：

• 回调内立即补充缓冲区：一旦收到WIM_DATA消息（表示当前缓冲区已满），第一时间在回调函数里调用waveInAddBuffer加入下一个已准备好的缓冲区。避免在回调中执行耗时操作，保证该步骤高效完成。
• 合理设置缓冲区大小：缓冲区不宜过小（否则回调过于频繁易卡顿），也不宜过大（会增加延迟）。建议按100-200ms的音频数据量计算，公式为：

  缓冲区大小 = 采样率 × 声道数 × (采样位深/8) × 缓冲时长(秒)
  

• 确保缓冲区准备流程正确：每个缓冲区首次使用前必须调用waveInPrepareHeader，不再使用时调用waveInUnprepareHeader，禁止重复准备仍在队列中的缓冲区。
• 避免主线程阻塞等待：绝对不能在主线程中等待缓冲区填满后再添加新缓冲区，必须依赖回调异步处理，否则必然出现音频间隙。

重要提醒 #

无需担心单缓冲区模式会导致音频间隙——只要回调中补充缓冲区的动作足够及时，WASAPI底层会保证音频流的连续性。若需要更灵活的缓冲区控制能力，建议直接改用WASAPI，它比MME更适配现代Windows系统，在低延迟场景下表现更优。

内容的提问来源于stack exchange，提问作者Barvinok