5 ms·

I can't say I've had the same experience, I've been using jackd successfully for around 15 years now. The modern Linux answer to audio fragmentation is Pipewire

I can't say I've had the same experience, I've been using jackd successfully for around 15 years now. The modern Linux answer to audio fragmentation is Pipewire, and that should actually have less fragmentation than on Windows because it preserves ABI compatibility. (It's not entirely stable yet though)

hctaw 6y ago
More fragmentation is not the solution to current fragmentation...
- cycloptic 6y ago
  I'm not sure what you mean. Pipewire goes out of its way to have ABI compatibility, so all your old applications using Pulse/Jack will just work.
  - account42 6y ago
    What about ALSA or OSS applications?
    - cycloptic 6y ago
      I believe there is a pipewire ALSA module, and for OSS there are (were?) numerous ways to get that emulated in ALSA.
      - account42 6y ago
        Ok so it should not be worse than pre-PipeWire at least. Too bad Linux can't just make /dev/dsp be usable by multiple applications like the *BSDs managed.
- atoav 6y ago
  While I usually would say the same, as I understood pipewire they are trying to create a unifying abstraction layer with a stable API that handles the underlying cruft. While I would have wished for a good clean solution from the start, the state of the current Linux Audio stack doesn't IMO really allow for such a solution without breaking every program ever. If Linux Audio needs one thing it would be something that handles the weird relationships between ALSA/Pulseaudio/Jack in a clear and automatic fashion. Because as for now I have seen Linux Sysadmins with 30 years of experience tear their hair out because they couldn't wrap their head around Linux Audio. Build a blackbox around it and try to rework it on the inside.
da_big_ghey 6y ago
Pipewire API is stable as of pretty recently: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#is-pipewire-ready-yet https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ... It already works better than pulse for bluetooth stuff, by a long shot. wtay is a good guy who is committed to the project, as opposed to the pulse maintainers who are jerks.
- nikanj 6y ago
  Alas, stable API doesn't mean the software itself is actually stable and bug-free
  - da_big_ghey 6y ago
    Definitely fair; I still encounter bugs. But that was true of pulseaudio as well, and it is true of pipewire to a significantly lesser extent, especially around bluetooth profile switching, interoperability with jackd, etc.
    - ahartmetz 6y ago
      The Pipewire author is the guy who basically made GStreamer good by overhauling its core logic back in the day - he really knows what he is doing. I fully expect that Pipewire will make audio on Linux really good (latency of Jack, consumer audio feature set of Pulseaudio, reliability of GStreamer) when it's done.
- pitterpatter 6y ago
  >as opposed to the pulse maintainers who are jerks. That doesn't seem fair to just throw out without proof. In all the interactions I've seen them in, they've come across alright for the most part.
  - da_big_ghey 6y ago
    Sure, here's a good example: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/227 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge... Maintainers unresponsive, talking about making changes but not following up. They strung the guy along for quite a while on this new codec selection mechanism problem. They claim to be in a v14.0 freeze for two months. He updated his code to work on new v14.0 to more unresponsiveness from maintainers about merging. And it goes on from there. If you've had to use pulseaudio-modules-bt or pali's patched version rather than official pulse, this is why. By comparison, pipewire managed to get it working with little effort because its lead developer is a nice guy and responsive.

hctaw 6y ago

More fragmentation is not the solution to current fragmentation...

cycloptic 6y ago
I'm not sure what you mean. Pipewire goes out of its way to have ABI compatibility, so all your old applications using Pulse/Jack will just work.
- account42 6y ago
  What about ALSA or OSS applications?
  - cycloptic 6y ago
    I believe there is a pipewire ALSA module, and for OSS there are (were?) numerous ways to get that emulated in ALSA.
    - account42 6y ago
      Ok so it should not be worse than pre-PipeWire at least. Too bad Linux can't just make /dev/dsp be usable by multiple applications like the *BSDs managed.
atoav 6y ago
While I usually would say the same, as I understood pipewire they are trying to create a unifying abstraction layer with a stable API that handles the underlying cruft. While I would have wished for a good clean solution from the start, the state of the current Linux Audio stack doesn't IMO really allow for such a solution without breaking every program ever. If Linux Audio needs one thing it would be something that handles the weird relationships between ALSA/Pulseaudio/Jack in a clear and automatic fashion. Because as for now I have seen Linux Sysadmins with 30 years of experience tear their hair out because they couldn't wrap their head around Linux Audio. Build a blackbox around it and try to rework it on the inside.

da_big_ghey 6y ago

Pipewire API is stable as of pretty recently: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#is-pipewire-ready-yet https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ... It already works better than pulse for bluetooth stuff, by a long shot. wtay is a good guy who is committed to the project, as opposed to the pulse maintainers who are jerks.

nikanj 6y ago
Alas, stable API doesn't mean the software itself is actually stable and bug-free
- da_big_ghey 6y ago
  Definitely fair; I still encounter bugs. But that was true of pulseaudio as well, and it is true of pipewire to a significantly lesser extent, especially around bluetooth profile switching, interoperability with jackd, etc.
  - ahartmetz 6y ago
    The Pipewire author is the guy who basically made GStreamer good by overhauling its core logic back in the day - he really knows what he is doing. I fully expect that Pipewire will make audio on Linux really good (latency of Jack, consumer audio feature set of Pulseaudio, reliability of GStreamer) when it's done.
pitterpatter 6y ago
>as opposed to the pulse maintainers who are jerks. That doesn't seem fair to just throw out without proof. In all the interactions I've seen them in, they've come across alright for the most part.
- da_big_ghey 6y ago
  Sure, here's a good example: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/227 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge... Maintainers unresponsive, talking about making changes but not following up. They strung the guy along for quite a while on this new codec selection mechanism problem. They claim to be in a v14.0 freeze for two months. He updated his code to work on new v14.0 to more unresponsiveness from maintainers about merging. And it goes on from there. If you've had to use pulseaudio-modules-bt or pali's patched version rather than official pulse, this is why. By comparison, pipewire managed to get it working with little effort because its lead developer is a nice guy and responsive.