On Sun May 3 22:47:19 2026 +0000, Dzmitry Keremsha wrote:
Why loud? Yeah maybe not the most appropriate description, in my head underflow = loud, overlap = quiet, deleting data sounds like an underflow, hence loud. (EDIT: actually it's not like an underflow, but it would most likely be very noticeable and not a proper solution either way) My exact pulse.properties config in \~/.config/pipewire:
#server.dbus-name = "org.pulseaudio.Server" #pulse.allow-module-loading = true pulse.min.req = 480/48000 pulse.default.req = 480/48000 pulse.min.frag = 480/48000 #pulse.default.frag = 96000/48000 # 2 seconds #pulse.default.tlength = 96000/48000 # 2 seconds pulse.min.quantum = 480/48000 #pulse.idle.timeout = 0 # don't pause after underruns #pulse.default.format = F32 #pulse.default.position = [ FL FR ] #pulse.fix.position = [ FL FR ]Allows for 10ms mmdev period with PULSE_LATENCY_MSEC=60 (so I can properly log without underflows) For clarity 15ms was quant 256+PULSE_LATENCY_MSEC=60, hence that was in the log i sent. Quant 256 without the variable is 10ms so that'd be good as well, but then underflows with logs. I have done extensive testing in the past few days and here are my observations:
1. No drift whatsoever with a virtual sink after an hour of logging. 2. The timer math looks correct and there are no truncation errors, mmdev usec is 10000. It might be possible that pulse is consuming based on the soundcard clock which could be at 47999 sample rate instead of 48000, in which case overfill is unavoidable even with a perfect timer. One way to solve this would be a dynamic resampler, which did seem to work in my testing, does not affect held_bytes and is absolutely unnoticeable. What do you think about this idea? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10792#note_138984