On Tue May 12 00:48:03 2026 +0000, Paul Gofman wrote:
no light games when using Proton requires it, and only a very rare heavy game does. It might be that in CPU heavy games under CPU starvation the game's + Wine audio threads do not keep up. What does 'ulimit -e' say? If it is not negative It might be that allowing thread priority increase for user (by editing /etc/security/limits.conf) can work better. if you run with WINEDEBUG=+server, do you see ("wine: RLIMIT_NICE is \<= 20, unable to use setpriority safely\\n") messages? If yes, Wine can't alter priorities due to limits. While unrelated here, I went ahead and pushed the updated patch version to the current Proton Experimental bleeding-edge branch (see https://github.com/ValveSoftware/Proton/wiki/Proton-Versions#proton-bleeding...), if you want to try with Proton you can use that version (experimental-bleeding-edge-11.0-359342-20260512-pd2f45d-w4531de-d6e9b50-v4ed1fe) ulimit -e is 31, so niceness goes down to -11 as I understand? Should be fine then. No complaints in logs either. The soundcard itself is quite performant on linux in my experience with DAWs.
The CachyOS kernel does help with underflows too. For instance when I was on Fedora: * Default kernel in Honkai with 480 quant for pw-pulse: crackles * CachyOS kernel with the same parameters: doesn't crackle This is specifically about underflows, it did not prevent the drift. Winealsa does perform better but that's highly likely simply because tlength of winealsa is \~1.5x of winepulse tlength at the same quant. Could it be that tlength of 20ms (9600) is just not enough? I don't really know how much latency there is on Windows to compare. Maybe the timer drift played some role somehow, the only game on CachyOS that crackles with quant 480 for me so far is Neverness to Everness and it happens very rarely, so that'd be quite annoying to test. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10792#note_139524