On Sun Jan 25 09:49:13 2026 +0000, Dzmitry Keremsha wrote:
Looked at what winealsa does, it seems the logic there is similar to my "safe_bytes" logic. If the audio server is slow - throttle pointer advancement. Since NtSetEvent is consistent, it eventually leads to full buffer RAM and denied refills. I guess this is okay? I don't know where this data goes then, but it never sounds like a part of audio is missing. It was easy to implement it with 5x timer polling without breaking anything, every tick add +1 to a counter, every 5 ticks (so exactly once per period) fire NtSetEvent. At stream start make the counter equal 4 so it would fire immediately. Passes tests, doesn't crackle, and unless I misunderstand something, looks exactly like winealsa to the game. Attaching a winealsa log with some additional logs from me so it's clear when a refill is missed. [honkai-winealsa.tar.gz](/uploads/c12ab1c11a1c36e7cf3bd784ec5bdf43/honkai-winealsa.tar.gz) I think I have found a genuine catch-22. held_bytes \< pa_held_bytes means pulseaudio server is slow and write and read pointer collision is imminent at some point. This is why ZZZ and ARC Raiders have a static buzz. We can make held_bytes stop advancing when it approaches pa_held_bytes and it would solve the problem, we would just wait for the server to catch up.
This is basically what winealsa does. But when I tried running tests in docker, the virtual audio hardware never moves, and pa grows way above held. But then how is it possible that winealsa doesn't fail tests? To see what is going on, I ran WINEDLLOVERRIDES="winepulse.drv=d" ./wine dlls/mmdevapi/tests/i386-windows/mmdevapi_test.exe spatialaudio and sure enough, I get the same 106 errors in spatial audio tests with winealsa as I do with winepulse if I stop the advancement. The winepulse driver assumes the audio server is never slow, which is not true in the real world. It's better to skip a refill than to end up with a static buzz, because a skipped refill won't be noticeable for the user. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9840#note_127995