3 ms·

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

by stinos 3y ago

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?

cwillu 3y ago
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.
jauntywundrkind 3y ago
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/ https://lwn.net/Articles/951337/
- cwillu 3y ago
  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.
- cwillu 3y ago
  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.
  - jauntywundrkind 3y ago
    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.
    - cwillu 3y ago
      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).

by stinos 3y ago

cwillu 3y ago

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.

jauntywundrkind 3y ago

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/ https://lwn.net/Articles/951337/

cwillu 3y ago
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.
cwillu 3y ago
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.
- jauntywundrkind 3y ago
  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.
  - cwillu 3y ago
    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).