Hacker News Reader

Comment by cwillu | Hacker News Reader

Note that in spite of what is said, this is not remotely equivalent to the true rt patchset for low latency. They switched ubuntu studio to the non-rt “lowlatency” and all of a sudden I have to increase my audio buffers by about 10x to get jack to run xrun free, which leads to some pretty horrific latency on a midi keyboard.

I can easily run buffer sizes for 0.5ms latency on the rt patchset while running random twitch streams and games at the same time, but struggle to maintain 10ms on lowlatency without xruns with everything but the core audio apps shut down.

View on HN

Are there distros for which this is fixed out of the box already? About 20 years ago we were writing a cross-platform application which required relaltively low latencies (2-5mSec IIRC) for audio with some of the RME interfaces. On Windows (with ASIO) and MacOS (don't remember) this basically just worked and we'd only have to take care not to run too much other heavy bandwith applications at the same time. On any of the *nixes out there it was completely hit or miss. Even after the struggle to get the correct drivers working, it required a myriad of seemingly obscure tweaks and kernel builds only to result in a system which was usually rather unstable at best. Plus the realization that it would be pretty much impossible to ship this because it would require the other party to also apply similar tweaks specific to their distro. I would have thought 20 years would be enough to mature this especially in major distros like Ubuntu but appaprently that is not the case?

Wow that sounds awful.

I've had no trouble plugging in random PCIe or USB devices and getting <6ms buffers. Everything works fine. After some years deeply enjoying JACK's incredible flexibility & latency, I eventually switched to PulseAudio with mostly stock config but much reduced buffers.

Now a days PipeWire is the best of both worlds. It'd be interesting to see if the top post still had such issues as they do under PipeWire, although I'm unsure what about pipewires scheduling would have better mechanistic sympathy.

Plenty of distros do offer -rt kernels. But -rt has been a massive set of patches for a long long time, and it's a different operating mode, and it has tradeoffs. Extreme latency sensitivity is a niche need, and giving it to everyone would have negative impacts. That's why it's not the default. Good news though, -rt's longkng effort to upstream appears to be nearing a successful conclusion, so realtime may be a Kconfig away in the future. We just have to solve printk() first, ha! https://lwn.net/Articles/951337/

6ms is still noticeably laggy for an instrument. It's not unplayable, you can get used to it, but 0.5ms feels like opening a window after sitting in a stuffy room in comparison. It's easily a reduction by half of the total end-to-end latency between pressing a key and hearing a sound.

Pipewire has basically nothing to do with anything. It mostly achieves what jack already does, which is fine, but it can't magically fix a kernel that can't consistently maintain a 0.5ms deadline on servicing a user process.

Agreed in principle, but I think it is possible that JACK or PipeWire have a slightly better implementation that has more mechanistic sympathy with the kernel.

Maybe pipewire's use of DMA-BUF lets it deliver to the audio device faster, or maybe jack has a slightly better event loop/thread architecture. (Just making up random hypothesis here; these aren't real claims.)

It's not going to deliver miracles; you're right that these two systems attempt very similar tasks. But there is some variance of implementation, and likely both of these systems have some small overhead. Maybe jack already delivered the absolute best responsiveness that could be possible in the kernel, had found every iota of optimization to make, and no new possibilities have emerged in the 20 years since. Or maybe jack already was p100 responsive to 0.00001ms, small enough to be effectively zero.

You're totally correct that the kernel is the limiting factor. But with audio we need p100, buffer underruns are never acceptable, and maybe one architecture let's us run stably with a slightly smaller buffer then the other architecture.

And maybe putting your pc on big concrete pads and using gold power cables makes a difference too. Unsupported conjecture is still unsupported even though it could in principle make a difference (to those not intimately familiar with the relevant engineering, at least).

Meh. Swearing there's no difference & being snarky about bothering to look isn't any better.

If you really are that confident in decades old JACK being best userland can possibly for p100, congrats on the long path of analysis that's lead you to that rightful confidence.

Thanks, sounds promising actually, or at least: not at all as I once experienced.

The only issue I ever have any more is the scheduler latency for the actual running software; the drivers have generally worked fine for all sorts of random (but class-compliant) devices.

Thank you for the warning (I run Ubuntu Studio on pretty much all my machines).

Reply on news.ycombinator.com