Comment by jauntywundrkind | Hacker News Reader

Comment by jauntywundrkind | Hacker News Reader

Parent Full thread

jauntywundrkind

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.

Reply on news.ycombinator.com