Conversely, in my own experience, Pipewire removed everything I held dear, destroyed my will to compute, and has somehow crippled my systems for the purposes of multitasking with any type of media playing.

Hyperbole aside, I'm glad someone was looking at the audio situation, but this one seemed to knock me out of the game on every machine that received it. Examples of common scenarios for me: I can't have firefox open and virtualbox at the same time, or bitwig and firefox, or visual studio and audacious. Common pairs of apps cause a bitrate mismatch for whatever reason, and everything sounds like a heavily bitcrushed and ring modulated signal.

The exception to this are machines that were installed with pipewire, rather than upgraded to pipewire. Also, using Cadence, a router type app helps, but inconsistently.

Do you mean sample rate? This may help https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Con...

Otherwise, have you raised the issue at https://gitlab.freedesktop.org/pipewire/pipewire/-/issues ? They're pretty responsive.

Does the PREEMPT_RT patchset matter wrt. audio latencies in Linux? That seems to be the biggest effort wrt. "low latency" workloads at least on the kernel side.

It does for latency and reliability, but in my experience running the xanmod kernel with just preempt without rt provides low enough (sub-5ms) latency that I stopped caring about RT in my home recording use.

5ms is an eternity, and without PREEMPT_RT I get xruns at 5ms on jack, which is (still) far better than pipewire on the same hardware.

Even with PREEMPT_RT, I can't even run 2ms pipelines without xruns.

I don't think this is within the realm of fixable. Linux simply isn't a good design for this. Kernel too large and unpredictable. Who knows when or if execution will return to userspace.

It depends on the use case, I'm quite happy with 5ms :-)

Ftr, on Pipewire on a Dell xps with iRig2, I'm getting 4.6ms reported with just PREEMPT. An xrun every few minutes if I try to go to ~2ms. I suspect I could get that working reliably with RT.

People are weird about this. Because audio is ultimately a vibration moving through the air, latency is equivalent to distance because sound can only travel a few hundred metres per second.

So, 5ms is less than two metres. When COVID-19 forced you to stand a little further away from people, did you find it added "an eternity" of latency to everything? No? You barely noticed? Right.

One exercise that's interesting is you can build a physical loop (e.g. speaker plus microphone) and play with how long it takes samples to leave your software, turn into audio, then re-enter and come back to your software. You might find that to your disappointment a software stack may be giving you just 256 samples of latency but your hardware adds say 8 milliseconds on top of that.

This approach also helps you ensure you're doing apples to apples comparisons.

Latency is the whole chain. That's Linux's latency, on top of everything else that could be there, such as however many meters of distance between speakers and listener in a live performance.

In no way is it acceptable for Linux to add 5ms to the chain.

Audio latency is only measured in the air once it leaves a transducer. You're comparing apples to oranges here and deliberately misunderstanding the issue.