Windows进程间实时音频缓冲区共享及VST反馈实现方案问询

核心可行方案 #

1. WASAPI + 共享环形缓冲区 #

• 这是实时音频场景的首选方案，依托Windows原生音频核心API，延迟可控（低延迟模式下可达几毫秒）。
• 实现逻辑：用CreateFileMapping创建跨进程共享内存，搭配MapViewOfFile让Sender和Receiver节点访问同一块环形缓冲区。Sender读取宿主分配的音频数据后写入缓冲区，Receiver从缓冲区取数。
• 关键细节：用Event或Semaphore做读写同步，避免数据冲突；严格匹配宿主的采样率、位深，保证音频格式一致。

2. WASAPI虚拟音频设备 #

• 借助虚拟音频设备（比如参照VB-Cable的原理），把Sender的输出作为虚拟设备的输入，Receiver直接从虚拟设备拉取音频流。
• 优势：不用手动处理内存同步，FL Studio Patcher这类宿主能像路由普通音频设备一样操作，适配自定义路由逻辑。
• 成本：用现成开源虚拟驱动可快速验证；自定义开发需用到Windows Driver Kit (WDK)，门槛较高。

3. MME跨进程音频流 #

• 兼容性拉满的旧API，延迟表现（10-50ms）能满足非极端实时需求。
• 实现方式：Sender用waveOutOpen打开虚拟输出，Receiver用waveInOpen对应虚拟输入，通过系统虚拟链路传输数据。缺点是延迟比WASAPI高，适合对延迟要求不苛刻的场景。

插件延迟处理方案 #

• 反馈回路必须处理插件延迟，你可以：
  • 从插件本身获取延迟参数：VST3用getLatencySamples，VST2用effGetLatency接口，拿到延迟样本数后在Receiver节点做延迟对齐，让反馈信号和当前输入时序匹配。
  • 结合FL Studio Patcher自带的延迟补偿功能，减少手动调整的工作量。

不推荐的方案 #

• DirectShow Filters：已被微软弃用，维护成本高，实时性不如WASAPI，直接排除。
• Audio Video Capture Feature/Source Reader：主打媒体文件、摄像头捕获，不是为低延迟实时音频传输设计的，不适合你的需求。

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