On Thu Apr 30 21:59:40 2026 +0000, Dzmitry Keremsha wrote:
I actually compared your PR to old winepulse and indeed it seemingly was starting to crackle a lot faster with the old one. The problem is that pointers still overlap maybe half an hour in even with your patch. The problem is widespread (from my experience on forums and such), but unfortunately I only have one PC at my disposal. If i can provide some additional logs for this I'd be happy to, but I need to know what exactly besides the ones proving pointers overlap. FWIW I tried two distros, two soundcards and different kernels. CachyOS kernel helps with underflows but it's a different issue altogether. Today with some help I tested:
Honkai Star Rail, Hades, Balatro Tested on three PCs, PC 1 and 3 for honkai, PC 1 and 2 for Balatro and PC 1 for Hades. All show the same behavior - slow timer drift. I attached a log that looks like this in the pulse.c code: ``` pulse_write(stream); TRACE("Buffer comparison: pa_held_bytes: %lu, held_bytes: %lu, diff: %ld\n", (unsigned long)stream->pa_held_bytes, (unsigned long)stream->held_bytes, (long)((long)stream->held_bytes - (long)stream->pa_held_bytes)); /* regardless of what PA does, advance one period */ adv_bytes = min(stream->period_bytes, stream->held_bytes); stream->lcl_offs_bytes += adv_bytes; stream->lcl_offs_bytes %= stream->real_bufsize_bytes; stream->held_bytes -= adv_bytes; ``` Tested Proton 11 and Proton GE, Proton GE had the last winepulse commit from Proton 10 without any additional patches, and Proton 11 is unchanged aside from the trace. Logged like this: WINEDEBUG=+pid,+loaddll,+timestamp,+debugstr,+threadname,+dsound,+dsound3d,+xaudio2,+mmdevapi,+pulse and PULSE_LATENCY_MSEC=60 to avoid crackling while getting the log spam. Without the latency variable, for example in Hades, I would get a very quick timer drift compared with frequent underflows (underflows do not happen without the logs so it's caused by them) [balatro-proton11-log.tar.gz](/uploads/8702ffc0fb47211004b28710591fb09d/balatro-proton11-log.tar.gz) To make sure this isn't about the differences in upstream Proton and GE, I tested Balatro with both and had the same outcome. I will only attach the Proton 11 Balatro log because of the size limits, however I can send the rest if needed. Regarding pipewire setup - everything is default and untouched except added RT capabilities on every machine. The pattern looks like this - winepulse timer is mostly in lockstep with the real time (by which I assume PipeWire). Sometimes, however, the audio server would consume less than it received, indicating that winepulse was a bit too fast. Since we don't have a throttling mechanism, we are now permanently ahead of reality. Wait long enough and the pointers would overlap and therefore it will crackle. An interesting discovery is that with the default pipewire-pulse quant of 256 (as of the new default in PipeWire 1.6) and PULSE_LATENCY_MSEC=60 the mmdevapi period is 15ms. In Honkai this is actually a huge problem - several crackles per second about one-two minutes in, specifically not underflow related. With the quant manually set to 480 - and therefore mmdevapi period becoming 10ms - there is a very slow drift which results in crackling in about 30 minutes for me. For PC 3 (pw-pa quant 480 and PULSE_LATENCY_MSEC=60) the drift actually only started occuring in 20-30 minutes of gameplay and was perfect before that. Yet another thing I noticed - the crackling is genuinely harder to spot when playing with speakers, for instance with bad HSR crackling and my laptop speakers I had to stand next to the speakers to hear them (probably something with the frequency they produce), while they are very loud and clear when listening through headphones. So as we can see, with the current winepulse timer implementation and without some sort of a throttling mechanism crackling is inevitable, be it in 10 minutes or 10 hours, at least on the hardware I tested. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10792#note_138566