3 ms·

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 co

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

by cwillu 3y ago

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