On Sat May 2 15:16:09 2026 +0000, Paul Gofman wrote:
Timer drift means that wine mmdevapi is slightly faster than pipewire (which is the real time), so the rate of refill is higher than the rate of consumption. It would be interesting why. Note that at least current time logic in Wine bases adjustments on PA stream time so it is supposed to match stream time of average. So if it consistently getting less writes and that builds up over some 30 minutes there might be some bug in that part (or some rounding error, so it would constistently err on one side somewhere estimating time or getting number of samples??). Note that this alone, while interesting, might not give the whole story anyway. Explanation sounds like this is the generic universal Wine problem, but this doesn't look to be the case. The audio doesn't crackle on the majority of setups for every game. There is no undertstadning currently what is special here, special inventive PA setup or maybe not but some issue with the specific game or engine (and the issue can in theory be in the specific audio API it is using even, e. g., xaudio). pa_held_bytes is permanently high now, any overfill = crackle. Since pa_held_bytes is at it's limit, it now happens quite frequently. Once again, the logic of app-visible update is an invariant, we are not free to change it to follow PA specifics without breaking compatibility with apps. But this is not the only option. I was mentioning an (rather complicated) alternative approach before. Another probably better way would be to just drop 'pa_held' buffer part once such a situation is detected. So at the moment of dropping it might have (probably hardly noticable?) hitch but then be fine for another half an hour. Either way, the way is it to adapt / interface PA side, not compromise app-visible side. For the latter approach with dropping PA buffer I personally would not be strictly opposed to that (unlike the current approach), even if there is no 100% understanding of the actual issue (which would probably be very useful to fix the actual problem). Dealing with the consequences which already happened for some reason (which reason can be incompatible PA setup out of our control) is probably better this way than letting pa_held_bytes stay permanently high. Honestly I am not sure myself what is happening either and why the reports aren't universal. So far there has not been a single case where I could play any game without the timer drifting (and surely enough crackling with enough time), and the problem has persisted across the hardware/kernels/etc I've tested.
I'd like to ask you what bad things can hypothetically can happen if held_bytes gets throttled - and I'd like to test some games/programs you know of where something breaking could happen. As it stands now - I am literally unable to play without crackling ever without either this patch or winealsa which basically does the same thing, so I am curious how the edge cases behave. Most games are fine though, they are okay with the fact that the audio thread can be stopped. Maybe it can cause something bad, but so far the logic I describe has to exist at least as a variable in downstream protons so people with such issues (me included) can play games without constant crackling half an hour in. If I understand correctly then the games that tie their game logic to mmdevapi would be a tiny bit faster when mmdevapi is fast, and if they hit the throttle they would slow down to compensate for their overspeed. Maybe I misunderstand something though. There have been no cases so far of games outright crashing or audio glitches from the public reports. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10792#note_138651