Windows下修改第三方进程音频输出至虚拟空设备的技术咨询

我需要实时将进程的音频输出重定向至其他位置，用WASAPI的AUDIOCLIENT_PROCESS_LOOPBACK_PARAMS有标准实现，但这个方法会让进程仍向默认输出设备播放音频。我想避免进程占用默认输出设备，让它输出到虚拟空输出音频设备，以下是可行的解决思路：

一、直接引导进程输出到虚拟空设备 #

• 先部署虚拟空输出设备：安装类似VB-Cable的虚拟输出模式驱动，或者专门的Null Audio Driver，这类设备会接收音频数据但不进行实际播放。
• 若进程支持自定义输出设备：直接在进程的音频设置里选择虚拟空设备即可，无需额外修改。
• 若进程强制用默认设备：临时把系统默认音频输出改成虚拟空设备，但这会影响所有进程，适合单进程场景或临时使用。

二、针对单个进程替换默认设备识别的标准方法 #

Windows没有官方标准API可以单独让某个第三方进程识别自定义的“默认音频设备”，系统默认设备是全局设置，所有进程调用GetDefaultAudioEndpoint这类API都会返回同一个全局默认设备。

三、用Detours欺骗进程识别默认设备的最佳实践 #

如果要精准针对单个进程修改默认设备识别，Detours是可靠方案，核心思路是Hook进程中获取默认音频设备的WASAPI函数：

• Hook目标函数：重点Hook两个核心入口：
  1. 全局函数GetDefaultAudioEndpoint：进程通过这个函数获取默认输入/输出设备，Hook后返回虚拟空设备的ID。
  2. COM接口方法IMMDeviceEnumerator::GetDefaultAudioEndpoint：这是WASAPI获取默认设备的底层COM接口，需要Hook该接口的虚函数表。
• 实现Hook逻辑：
  1. 先枚举系统中的虚拟空设备，获取它的IMMDevice实例或唯一设备ID。
  2. 在Hook函数中，当目标进程请求默认输出设备时，直接返回预先获取的虚拟空设备实例，而非系统真实默认设备。
• 注入Hook到目标进程：
  1. 若进程未启动：用Detours的DetourCreateProcessWithDllEx函数，在启动进程时注入你的Hook DLL，确保进程加载时就完成Hook。
  2. 若进程已运行：用DetourAttach动态注入，但需要申请足够的进程权限，同时处理内存保护属性的修改。
• 注意事项：
  • 要处理COM对象的生命周期，确保返回的IMMDevice实例符合目标进程的COM运行环境要求，避免内存泄漏或崩溃。
  • 需针对不同Windows版本测试WASAPI的兼容性，避免系统更新导致Hook逻辑失效。
  • 严格遵循Windows API的调用规范，不要破坏进程其他音频相关逻辑的正常执行。

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