On Fri Jan 23 16:46:22 2026 +0000, Paul Gofman wrote:
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. We are not free to adjust app-visible state (e. g., we set app's event), that is something which should match Windows behaviour (fwiw, that is not exactly perfect now and that what I am trying to improve in the MR linked above, but in any case we shouldn't be making it to diverse more from Windows). One thing I wouid like to see in the log is how MM device is set up. Specified 'minreq' of 13.3ms is suspicious, minreq is based on mmdevapi 'period' and normally with shared device we should always end up with 10ms period (if pulse setup stipulates more period that setup is essentially broken for us, we can't really work that around and we have to maintain that 10ms to be compatible and avoid issues). Yet I can imagine maybe we can have some problem with those period rounding somewhere and maybe we should be fixing that one.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/9840#note_127782