Post by @yuman@programming.dev

2026-11-11 12:04 UTC

pipewire combine sink help please so I create a combined sink from two audio devices, my HDMI (DP actually) monitor with OK speakers and the analog stereo audio out, which got a subwoofer attached, without satellites. pactl load-module module-combine-sink, this works swimmingly, sound is awesome, I can set exact audio levels for each output, no notes. problem is, I’m listening to an internet audio stream via Rhythmbox (tried mp3s off a network share, same deal) and when there’s heavy CPU activity, the sound slows down, goes oooOOooOooOOoo like if you remember audio tapes from the olden days that got stretched/deformed. this only happens with the combined sink, if it’s just HDMI audio, no issues. used to happen infrequently, only when launching games or android studio doing compiling but nowadays with every other site having some cloudflare/anubis-like CPU torture, it’s getting really tired, really fast. tried looking at htop, pw-top, following the journal but nothing of substance is observable; possibly because this lasts for a second or so and those tools ain’t exactly real-time. maybe the issue is the devices being 48 KHz whilst the stream is 44.1 and there’s some resampling happening? tried looking at pipewire/wireplumber documentation but that stuff is way above my head; “quantums”, wtf?! so is there some priority I can elevate or something so that this audio stack doesn’t get compromised? I don’t wanna give up the setup nor Rhythmbox. Fedora, Plasma, Wayland, i5-4670, RX 580.

Replies (1)

@Obin@feddit.org 2026-11-11 17:30

there’s some resampling happening? This isn’t a trivial problem to solve in software and will always be YMMV. What you have to understand is that despite it saying your devices are both 48kHz, they’re actually not. They’re either running a bit slow (think 47.982kHz or something like that) or a bit fast (like 48.005kHz), so one will always take the data out of your buffer a bit faster than the other. If this is not compensated by duplicating samples or upsampling, then downsampling twice (with some kind of PLL in between), the buffer is going to run out at some point for one of the outputs. Pipewire is likely trying to compensate for that as described, but that isn’t free (more than double the work it has to do on a single output) and when something takes a lot of CPU time this can starve Pipewire out. The quantum you’ve read about is essentially the size of that buffer I mentioned above and the bigger you make it, the more slack Pipewire has to work with before the buffers get depleted. This translates directly to a latency in ms if you divide this number by the samples per second (i.e. the frequency), so 2048 like below would translate into 42ms. Note that your sound device will have its own internal buffer that also adds latency on top of that. I’ve had the following in my Pipewire config for years at this point because I had constant crackling in my (single) output when the CPU was under load: context.properties = { default.clock.min-quantum = 2048 } I’m not sure if this is still the suggested way to configure this, but it has worked well for me over the years. (Or maybe it’s dead configuration and the problem went away on its own separately, who knows… maybe time for me to look at this again.)

Open ##5519982