Massive Latency spike on xrun/delay

So I have a problem at work that has been escaping me for a few days now and I'm hoping someone here might be able to provide insight.

I'm running into a situation where it seems pipewire (or potentially lower in the linux audio stack) builds up a massive buffer when the graph is even remotely late. I'm working on a announcement system and about 1 in 15 announcements run into this problem. Normally there is next to no latency but when is xrun occurs latency can be as bad as a full second. Audio is never dropped... which is why I suspect a buffer is just growing massively in this situation. Does anyone know if there's a buffer in pipewire that's capable of growing that massive? If so, is there a way to make that stop? I'd rather lose the audio than let a full second build up in the system

Heres some information on the graph I'm creating:

Source node:

  • audio.rate: 40/8000
  • periods: 2
  • pipewire stream client

Sink node:

  • audio.rate: 256/48000
  • alsa period-num: 2
  • alsa sink node

Graph config:

  • Quantum (both min and max as well): 256
  • Link buffers: 2

My current theory is that.... When the graph misses its timing, whatever buffer is being used for for the resampling grows indefinitely until the timing of the between 40/80 and 256/48000 can be aligned. Unfortunately, my audio card doesn't seem to support a none power of 2 quantum so it will always negotiate 256. So there will always be a weird offset in timing between the source and sink in this particular case.

I had a whim to post this just now because its bugging me. I'll see if I can post my exact config tomorrow. Figured I'd ask around here before I go digging through the source code.

Posted Sep 17, 2026, 3:22 AM UTC

15
Loading comments…