13 ms·

PipeWire 0.3 – JACK compatibility layer with comparable performance to JACK2

128 points by c487bd62 7y ago

BlackLotus89 7y ago
I tried getting it running and working two weeks ago and sometime today as well. I had some real problems getting it working. The compilation ran without a hitch, but getting jack, alsa or pulseaudio to work wasn't really possible. Wanted zo open bug reports and read the wiki on github but they moved it to the freedesktop gitlab, but didn't update the links. Also the pages are mostly out of date or without any relevant information, but plans. Can't wait to get a seamless setup for it, but I guess 0.3 is still too early for early adopters...
misterbishop 7y ago
Jack, while incredibly powerful has been a huge hurdle for pro audio on Linux. I'm looking forward to Pipewire being the default audio interface. Hopefully it drives a revival of the Linux sound engineering community and new software projects. Specifically the lack of a user friendly loop/sample-based recording tool like Ableton Live is glaring.
- scns 7y ago
  Check out Bitwig
  - paulie_a 7y ago
    Does it work with a launchpad? Or is there any other options that do? Ableton and virtualdj are literally the only pieces of software I keep windows for. Edit: sidenote is there any software works with a mixtrax3
    - unixhero 7y ago
      Bitwig was created by Ableton employees.
- cycloptic 7y ago
  Can you describe what some of your hurdles have been? Pipewire is probably not going to solve your issues as it's not a complete replacement for JACK [0] and uses the same API anyway. Realistically, if you're writing a new DAW, you're still going to want to use the JACK API. If your problems are driver-related, that definitely won't be solved by switching to a different audio daemon. And for the record, the open source audio community is not dead. There is activity, but you have to know where to look. [0]: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#will-pipewire-ever-be-as-good-as-jack https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ...
  - cjsthompson 7y ago
    Before giving others lessons you should get your facts straight. PipeWire is meant to be a complete replacement for not only JACK, but also PulseAudio. One of it's goals is to merge the functionality of both of these and only provide a compatible API for apps as a convenience. It will be possible to write apps that don't use these. Internally it's different from JACK and PulseAudio. Other goals include better latency and better handling of dynamically plugged audio interfaces which is currently a mess with JACK. It's also an attempt at simplifying the linux audio stack.
    - cycloptic 7y ago
      I'm going by what's in the FAQ that I linked. I already gave you the primary source of whatever facts I have so take it up with them, not me. If it's wrong, and you have the ability to edit it, can you fix it?
      - mappu 7y ago
        I have no skin in this game but I presume a DAW would not use any of the dynamic graph configuration / format conversion stuff and just generate its own PCM buffers in userspace. In this case JACK's primary draw over PA/alsalib/whatever is solely the lower latency, for responsiveness in live performances. This FAQ makes Pipewire out to be very similar to JACK but with more features. It is full of references to how Pipewire can achieve low-latency. e.g. In the "is PipeWire another JACK implementation" it boasts ""Synchronous clients are providing data for the current processing cycle of the device(s). There is no extra period of latency."" Of your bullet points vs JACK, the first is a genuine latency issue but should be fixable (""we are not there yet""), maybe in the kernel driver or by special-casing this particularly simple path in Pipewire. The rest are CPU overheads but not really latency-specific, especially not in an ongoing way for an established / security-checked graph from the DAW. I think I read this FAQ quite differently from you, I see a lot of understated optimism here and I think it is reasonable to expect Pipewire to supplant JACK (and obviously Pulseaudio too) in the future for all use cases. It will be a phenomenal simplification of the Linux A/V stack to get behind a single comprehensive implementation.
- jcelerier 7y ago
  > Specifically the lack of a user friendly loop/sample-based recording tool like Ableton Live is glaring. Slowly I'm trying to get https://ossia.io https://ossia.io there... any help appreciated :D
  - Intermernet 7y ago
    Wow, that's not a Live competitor, that's a new paradigm! Definitely going to check it out and see if I can help in any way!
    - jcelerier 7y ago
      It's a superset of loopers, timelines and patcher :) but i'm almost alone on it so development is not as fast as it could be
- PaulDavisThe1st 7y ago
  The reasons why a tool like Live exists or does not exist on a platform has essentially zero relationship to the APIs used for audio and MIDI I/O. As others have noted, Bitwig already exists - in some ways, it is more powerful than Live (and in others, less). It is also proprietary. Also, Live is not the kind of tool that most people would associate the term user friendly with. It's quite hard to get started using Live, despite the program being basically 100% awesomesauce. Live is extremely friendly towards a certain kind of workflow for "in-the-box" music production, and has fundamentally changed the entire zeitgeist surrounding making music with computers. But it's not a replacement for linear timeline DAWs (like ProTools, Logic, Sonar, Ardour etc. etc.) and has its own foibles and certainly its own complexities and limitations. I anticipate that the next major release of Ardour will have some Live-like features starting to arrive.
  - ivarv 7y ago
    > I anticipate that the next major release of Ardour will have some Live-like features starting to arrive. This is pretty intriguing - is there a public roadmap for these Live-like features ?
    - PaulDavisThe1st 7y ago
      We don't have enough developer resources to make roadmaps a worthwhile thing to spend time on. I work on this stuff when I am inclined and when there don't seem to be more important things to work on. Also, just to be clear, I said "the next major release" because in my own head, 6.0 is "almost upon us". What I meant was the next major release after 6.0.
- zokula 7y ago
  I wouldn't be too quick to assume that Pipewire will be the default anywhere.
- johnr2 7y ago
  > Jack, while incredibly powerful has been a huge hurdle for pro audio on Linux. For me JACK was a huge step forward. After 25+ years of recording on tape, JACK allowed me to switch to computer based recording ~14 years ago. It did away with a lot of the arbitrary restrictions on what connections were allowed in the audio software that was around at the time (and which made me unwilling to switch until that point).
PaulHoule 7y ago
Note this is developed by a Red Hat engineer, so this is an an open source IBM contribution to Linux.
8bitsrule 7y ago
Good news to see work being done on the Linux-audio 'bottleneck'. I miss the ease-of-use and options available on other platforms (I left behind).
- PaulDavisThe1st 7y ago
  Trust me, the device audio/MIDI APIs are not the bottleneck. Things like JACK (which tend to draw complaints) don't exist on other platforms (except ... by running JACK there), so complaining about its complexities (not that you did, explicitly) isn't really fair since that is based on an apples-to-oranges comparison. I would guess that the options you miss are the result of application and plugin developers (not) being willing to include Linux in their target platforms. As cool as PipeWire might turn out to be, it isn't going to have much effect on those decisions. Finally, lots of people seem to manage to forget how for years (decades, perhaps), high performance audio software on Windows required new device drivers (ASIO) for your audio hardware, because the ones that came with Windows couldn't do the job. This has mostly changed now, but ASIO is still with us nevertheless.
  - RossBencina 7y ago
    I don't know whether the audio APIs are a bottleneck for programmers, but for me complexity of _configuring_ ALSA[1] is a massive bottleneck to expecting _average users_ to be able to do prosumer audio on Linux. With ASIO on Windows, all the user need do is install the driver and then select the ASIO device in their application. On Linux, if something is wrong with your ALSA config, you need to break out the text editor and become an expert in ALSA architecture and configuration. I've seen enough lost souls in this situation asking questions on mailing lists that I am convinced it is a major problem. As someone interested in deploying an end-user application to Linux, the fact that there is no plug-and-play "it just works" solution[2] for low-latency audio is a big problem. [1] More specifically: resolving misconfiguration. [2] By this I mean a solution that works by design, not by luck.
    - cycloptic 7y ago
      Pipewire is probably not going to make your ALSA configuration issues go away. It's built on top of ALSA just like everything else. What it might do is make it easier to have low-latency audio across multiple devices. And it may save you some of the hassle of having to configure JACK and LADISH. Would you care to mention what your device and particular misconfiguration problem is? I can't guarantee I can help, and if it turns out the issue is due to drivers then there's not really anything a sound server like Pulse/JACK/Pipewire can do about it. You can't design around that, it literally is just bad luck that you happened to have a device that is badly supported.
techntoke 7y ago
Does this mean we'll finally see Zoom screen sharing with Wayland? Hope the Zoom team gets this resolved soon.
hootbootscoot 7y ago
Starting Jack and then patching stuff together was never an issue to me. It's not any more complicated than your imagined use-case for it, aka "patch program A into progam B" ALSA is horridly complex and it's complexity is related to Linuxy stuff, not to anything resembling the work your actual audio converters are doing nor the task of getting data in and out of them! A new layer added on top of ALSA will not fix this. Nothing will fix this until some AUDIO people, who are NOT Posix Linuxy People write a realtime audio subsystem to REPLACE ALSA. This will not occur anytime soon, for several reasons. Both the Bela.io system and Elk's "brand new audio OS from the ground up" (LOL) utilize Linux but bypass ALSA to achieve their low-latency rock-solid audio pipeline. (the CTAG interface that Heinrich Langer designed appears to be the first example I can find of this approach) They use Xenomai realtime kernel extensions to Linux to essentially run the audio driver as a real-time thread and the buffers your program writes to/reads from, are the actual buffers that DMA is moving the audio data in and out of to the ADC and DAC. End of the day, audio isn't a posix API, and should never be considered as such. Want an abstraction? fine, wrap a callback as an audio server lol... I had a Tascam USB audio interface that always sounded THIN on Linux and I wondered why, until I saw that the ALSA channel mapping had automagically applied a surround sound map to my 8 channels of output, which implied two lovely high-pass filters running at 75hz because the system was quite sure that's what everyone does with 8 channels of output... this despite the fact that ALSA saw 4 different stereo "devices" as my hardware interface presented itself... IF ONLY this were merely a universally understood /etc/alsa.conf or something file... oh no no no! Linux People have SAVED us from audio configuration! Go look in /opt/didntknowthisfolderexisted/.confy/map.conf or maybe somewhere else... Add x-windows and the lack of any GUI application corresponding 1-to-1 with the "handy obscure utility" it purports to configure and control, and you have a match made in heaven! Linux is an awesome server OS. It's a crap audio OS, and this is due to extreme cleverness and a total lack of paying attention to how any other audio API's in the world work except OSS... OSS isn't even an audio API FFS! it's like a printer API... you might as well use CUPS to run your sound LOL

128 points by c487bd62 7y ago

I tried getting it running and working two weeks ago and sometime today as well. I had some real problems getting it working. The compilation ran without a hitch, but getting jack, alsa or pulseaudio to work wasn't really possible. Wanted zo open bug reports and read the wiki on github but they moved it to the freedesktop gitlab, but didn't update the links. Also the pages are mostly out of date or without any relevant information, but plans. Can't wait to get a seamless setup for it, but I guess 0.3 is still too early for early adopters...

misterbishop 7y ago

Jack, while incredibly powerful has been a huge hurdle for pro audio on Linux. I'm looking forward to Pipewire being the default audio interface. Hopefully it drives a revival of the Linux sound engineering community and new software projects. Specifically the lack of a user friendly loop/sample-based recording tool like Ableton Live is glaring.

scns 7y ago
Check out Bitwig
- paulie_a 7y ago
  Does it work with a launchpad? Or is there any other options that do? Ableton and virtualdj are literally the only pieces of software I keep windows for. Edit: sidenote is there any software works with a mixtrax3
  - unixhero 7y ago
    Bitwig was created by Ableton employees.
cycloptic 7y ago
Can you describe what some of your hurdles have been? Pipewire is probably not going to solve your issues as it's not a complete replacement for JACK [0] and uses the same API anyway. Realistically, if you're writing a new DAW, you're still going to want to use the JACK API. If your problems are driver-related, that definitely won't be solved by switching to a different audio daemon. And for the record, the open source audio community is not dead. There is activity, but you have to know where to look. [0]: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#will-pipewire-ever-be-as-good-as-jack https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ...
- cjsthompson 7y ago
  Before giving others lessons you should get your facts straight. PipeWire is meant to be a complete replacement for not only JACK, but also PulseAudio. One of it's goals is to merge the functionality of both of these and only provide a compatible API for apps as a convenience. It will be possible to write apps that don't use these. Internally it's different from JACK and PulseAudio. Other goals include better latency and better handling of dynamically plugged audio interfaces which is currently a mess with JACK. It's also an attempt at simplifying the linux audio stack.
  - cycloptic 7y ago
    I'm going by what's in the FAQ that I linked. I already gave you the primary source of whatever facts I have so take it up with them, not me. If it's wrong, and you have the ability to edit it, can you fix it?
    - mappu 7y ago
      I have no skin in this game but I presume a DAW would not use any of the dynamic graph configuration / format conversion stuff and just generate its own PCM buffers in userspace. In this case JACK's primary draw over PA/alsalib/whatever is solely the lower latency, for responsiveness in live performances. This FAQ makes Pipewire out to be very similar to JACK but with more features. It is full of references to how Pipewire can achieve low-latency. e.g. In the "is PipeWire another JACK implementation" it boasts ""Synchronous clients are providing data for the current processing cycle of the device(s). There is no extra period of latency."" Of your bullet points vs JACK, the first is a genuine latency issue but should be fixable (""we are not there yet""), maybe in the kernel driver or by special-casing this particularly simple path in Pipewire. The rest are CPU overheads but not really latency-specific, especially not in an ongoing way for an established / security-checked graph from the DAW. I think I read this FAQ quite differently from you, I see a lot of understated optimism here and I think it is reasonable to expect Pipewire to supplant JACK (and obviously Pulseaudio too) in the future for all use cases. It will be a phenomenal simplification of the Linux A/V stack to get behind a single comprehensive implementation.
jcelerier 7y ago
> Specifically the lack of a user friendly loop/sample-based recording tool like Ableton Live is glaring. Slowly I'm trying to get https://ossia.io https://ossia.io there... any help appreciated :D
- Intermernet 7y ago
  Wow, that's not a Live competitor, that's a new paradigm! Definitely going to check it out and see if I can help in any way!
  - jcelerier 7y ago
    It's a superset of loopers, timelines and patcher :) but i'm almost alone on it so development is not as fast as it could be
PaulDavisThe1st 7y ago
The reasons why a tool like Live exists or does not exist on a platform has essentially zero relationship to the APIs used for audio and MIDI I/O. As others have noted, Bitwig already exists - in some ways, it is more powerful than Live (and in others, less). It is also proprietary. Also, Live is not the kind of tool that most people would associate the term user friendly with. It's quite hard to get started using Live, despite the program being basically 100% awesomesauce. Live is extremely friendly towards a certain kind of workflow for "in-the-box" music production, and has fundamentally changed the entire zeitgeist surrounding making music with computers. But it's not a replacement for linear timeline DAWs (like ProTools, Logic, Sonar, Ardour etc. etc.) and has its own foibles and certainly its own complexities and limitations. I anticipate that the next major release of Ardour will have some Live-like features starting to arrive.
- ivarv 7y ago
  > I anticipate that the next major release of Ardour will have some Live-like features starting to arrive. This is pretty intriguing - is there a public roadmap for these Live-like features ?
  - PaulDavisThe1st 7y ago
    We don't have enough developer resources to make roadmaps a worthwhile thing to spend time on. I work on this stuff when I am inclined and when there don't seem to be more important things to work on. Also, just to be clear, I said "the next major release" because in my own head, 6.0 is "almost upon us". What I meant was the next major release after 6.0.
zokula 7y ago
I wouldn't be too quick to assume that Pipewire will be the default anywhere.
johnr2 7y ago
> Jack, while incredibly powerful has been a huge hurdle for pro audio on Linux. For me JACK was a huge step forward. After 25+ years of recording on tape, JACK allowed me to switch to computer based recording ~14 years ago. It did away with a lot of the arbitrary restrictions on what connections were allowed in the audio software that was around at the time (and which made me unwilling to switch until that point).

PaulHoule 7y ago

Note this is developed by a Red Hat engineer, so this is an an open source IBM contribution to Linux.

8bitsrule 7y ago

Good news to see work being done on the Linux-audio 'bottleneck'. I miss the ease-of-use and options available on other platforms (I left behind).

PaulDavisThe1st 7y ago
Trust me, the device audio/MIDI APIs are not the bottleneck. Things like JACK (which tend to draw complaints) don't exist on other platforms (except ... by running JACK there), so complaining about its complexities (not that you did, explicitly) isn't really fair since that is based on an apples-to-oranges comparison. I would guess that the options you miss are the result of application and plugin developers (not) being willing to include Linux in their target platforms. As cool as PipeWire might turn out to be, it isn't going to have much effect on those decisions. Finally, lots of people seem to manage to forget how for years (decades, perhaps), high performance audio software on Windows required new device drivers (ASIO) for your audio hardware, because the ones that came with Windows couldn't do the job. This has mostly changed now, but ASIO is still with us nevertheless.
- RossBencina 7y ago
  I don't know whether the audio APIs are a bottleneck for programmers, but for me complexity of _configuring_ ALSA[1] is a massive bottleneck to expecting _average users_ to be able to do prosumer audio on Linux. With ASIO on Windows, all the user need do is install the driver and then select the ASIO device in their application. On Linux, if something is wrong with your ALSA config, you need to break out the text editor and become an expert in ALSA architecture and configuration. I've seen enough lost souls in this situation asking questions on mailing lists that I am convinced it is a major problem. As someone interested in deploying an end-user application to Linux, the fact that there is no plug-and-play "it just works" solution[2] for low-latency audio is a big problem. [1] More specifically: resolving misconfiguration. [2] By this I mean a solution that works by design, not by luck.
  - cycloptic 7y ago
    Pipewire is probably not going to make your ALSA configuration issues go away. It's built on top of ALSA just like everything else. What it might do is make it easier to have low-latency audio across multiple devices. And it may save you some of the hassle of having to configure JACK and LADISH. Would you care to mention what your device and particular misconfiguration problem is? I can't guarantee I can help, and if it turns out the issue is due to drivers then there's not really anything a sound server like Pulse/JACK/Pipewire can do about it. You can't design around that, it literally is just bad luck that you happened to have a device that is badly supported.

techntoke 7y ago

Does this mean we'll finally see Zoom screen sharing with Wayland? Hope the Zoom team gets this resolved soon.

hootbootscoot 7y ago

Starting Jack and then patching stuff together was never an issue to me. It's not any more complicated than your imagined use-case for it, aka "patch program A into progam B" ALSA is horridly complex and it's complexity is related to Linuxy stuff, not to anything resembling the work your actual audio converters are doing nor the task of getting data in and out of them! A new layer added on top of ALSA will not fix this. Nothing will fix this until some AUDIO people, who are NOT Posix Linuxy People write a realtime audio subsystem to REPLACE ALSA. This will not occur anytime soon, for several reasons. Both the Bela.io system and Elk's "brand new audio OS from the ground up" (LOL) utilize Linux but bypass ALSA to achieve their low-latency rock-solid audio pipeline. (the CTAG interface that Heinrich Langer designed appears to be the first example I can find of this approach) They use Xenomai realtime kernel extensions to Linux to essentially run the audio driver as a real-time thread and the buffers your program writes to/reads from, are the actual buffers that DMA is moving the audio data in and out of to the ADC and DAC. End of the day, audio isn't a posix API, and should never be considered as such. Want an abstraction? fine, wrap a callback as an audio server lol... I had a Tascam USB audio interface that always sounded THIN on Linux and I wondered why, until I saw that the ALSA channel mapping had automagically applied a surround sound map to my 8 channels of output, which implied two lovely high-pass filters running at 75hz because the system was quite sure that's what everyone does with 8 channels of output... this despite the fact that ALSA saw 4 different stereo "devices" as my hardware interface presented itself... IF ONLY this were merely a universally understood /etc/alsa.conf or something file... oh no no no! Linux People have SAVED us from audio configuration! Go look in /opt/didntknowthisfolderexisted/.confy/map.conf or maybe somewhere else... Add x-windows and the lack of any GUI application corresponding 1-to-1 with the "handy obscure utility" it purports to configure and control, and you have a match made in heaven! Linux is an awesome server OS. It's a crap audio OS, and this is due to extreme cleverness and a total lack of paying attention to how any other audio API's in the world work except OSS... OSS isn't even an audio API FFS! it's like a printer API... you might as well use CUPS to run your sound LOL