找出VMware(/+Hyper-V)环境下爆音的原因了

xkai 此前有坛友提到VMware虚拟机在NT5.1+多处理器HAL下（开启Hyper-V的条件下）特别卡，经我测试，VMware Workstation 17.5下无此问题（自17.5之后我就没有升级过），无论是acpipic_up、acpiapic_up，还是acpiapic_mp，都不卡（但dxdiag的DirectDraw测试在1080p分辨率下第一步还是略卡，不过17.5的2D framebuffer无论开关Hyper-V都是略卡，也就无所谓了）。
（我看到上面的坛友在VMware社区发言说17.6减速的问题了）

但随之而来第二个问题，VMware的爆音无法解决了，在虚拟机中运行VMAudioFixTray、VMAudioBack、WMP均无效。
（之前同时运行着VirtualBox，反而未发现爆音问题）

最后发现VMAudioBackHost可以解决，原理是：
Windows 10 2004+的系统不再允许单个进程的timeBeginPeriod调用来全局修改计时器分辨率（但在Win11下修改注册表GlobalTimerResolutionRequests可以恢复旧行为）。
而Hyper-V的hypervisor造成了下面的结果（VMAudioBack、VMAudioBackHost作者原话）：

Windows Hypervisor/WSL/Sandbox related stuff caused VMware to use alternative code path, causing audio issue that cannot be resolved by playing music in Windows Media Player in VM.

致使虚拟机内部的计时器分辨率必须在外部（宿主机）修改才可以。

而Windows 10 2004+将计时器分辨率变为per-process后，外部（宿主机）运行计时器分辨率修改程序也修改不了vmware-vmx.exe的计时器分辨率。
VirtualBox运行时不爆音则可能是因为VirtualBox的部分驱动override了全局计时器分辨率。

最后通过VMAudioBackHost解决了VMware+Hyper-V环境下爆音的问题，但VMAudioBackHost仅可应用在已启动的vmware-vmx.exe进程，后面看Issues，有人开发了一个VMAudioBackHook，可以通过放置在vmware-vmx.exe路径下的winmm.dll Hook vmware-vmx.exe，使其计时器分辨率由15.625ms提升到1.0ms，最终解决了这个问题。

注：目前我的电脑仅使用CPU内部的高精确度ITSC计时源（为了解决莫名其妙的DPC延迟），传统计时源已经被关闭（如HPET等），如果Hook及更换17.5版本后仍未解决，可以尝试关闭HPET等传统计时源（不关闭时Windows似乎仍会优先使用ITSC，但如果仍有问题则需要关闭）：

bcdedit /set {current} useplatformclock no
bcdedit /set {current} useplatformtick no
bcdedit /set {current} disabledynamictick yes

（关闭HPET计时源、RTC计时源，及计时器节能）

bcdedit /deletevalue {current} useplatformclock
bcdedit /deletevalue {current} useplatformtick
bcdedit /deletevalue {current} disabledynamictick

（恢复默认值）