On Fri Jan 23 04:09:39 2026 +0000, Dzmitry Keremsha wrote:
Honkai seems to refill 441 frames every tick, while draining 470 (512 quant at 48k, the game is forced 44.1k). So that's a 29 frame bleed every tick, therefore crackling is mathematically guaranteed. My logic makes NtSetEvent dependent on held_bytes level, so it refills properly. EDIT: Sorry, this was an incorrect assumption and the difference is managed properly. The problem is indeed CPU stall sensitivity as in all other cases. Logs show last successful tick at the time 76702276705, and the next tick after an at the time 76702291787. The difference of 15082 microseconds or 15ms. So this is exactly the problem I was describing. I truly don't believe the general issue of winepulse crackling is limited to my setup. For instance, there are numerous reports of occasional static buzzing sound in Arc Raiders on protondb, with advice to switch to winealsa because it resolves the issue. I personally experienced that problem with the original winepulse, and it's gone with both winealsa and my fix. Thing is, the fix looks wrong, the period of audio ticks is constant on Windows (I presume the game works without crackling there?) and adjusting it dynamically, while maybe helps this specific game for some reasons, doesn't look right.
It needs to be understood what is the actual problem and why exactly the application underfills it. The very first thing is to understand which audio API the game is even using, is that mmdevapi directly, or maybe xaudio, or dsound? The problem might happen to be entirely not in [wine]pulse or mmdevapi in theory. Could you maybe attach the full (compressed) log recorded with WINEDEBUG=+pid,+loaddll,+timestamp,+seh,+debugstr,+threadname,+dsound,+dsound3d,+xaudio2,+mmdevapi,+pulse ? That will at least clearly show what API is being used and what if there is something special in how the audio is initialized. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9840#note_127781