Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PipeWire 0.3 – JACK compatibility layer with comparable performance to JACK2

github.com

Post reply on HN
Print view View original

21–30 of 44 posts

Re: PipeWire 0.3 – JACK compatibility layer with comparable performance to JACK2

#21

Post by mappu »

cycloptic wrote: post #16
cjsthompson wrote: post #9

Earlier quoted context omitted.

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…

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?

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.

Re: PipeWire 0.3 – JACK compatibility layer with comparable performance to JACK2

#22

Post by RossBencina »

PaulDavisThe1st wrote: post #18
8bitsrule wrote: post #14

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).

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) be…

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.

Re: PipeWire 0.3 – JACK compatibility layer with comparable performance to JACK2

#23

Post by cycloptic »

mappu wrote: post #21
cycloptic wrote: post #16

Earlier quoted context omitted.

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?

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 Pi…

Don't get me wrong, I personally am totally in favor of Pipewire. The GP was making it sound like it's going to be some kind of panacea though, and I don't think that is going to happen. Pro audio is hard. It takes a long time to bring a project like this up to speed (I know because I've been waiting patiently for the video streaming stuff to stabilize). Pipewire is a good improvement for users but it doesn't bring any major features that a DAW is going to really want. And as Paul said, eventually as a DAW grows and becomes more monolithic you're going to get away from even wanting an audio server at all so you can have the lowest latency possible.

BTW from my perspective there already is a major project driving a revival of open source audio, and that project is called JUCE [0].

[0] https://github.com/WeAreROLI/JUCE

Re: PipeWire 0.3 – JACK compatibility layer with comparable performance to JACK2

#24

Post by cycloptic »

RossBencina wrote: post #22
PaulDavisThe1st wrote: post #18

Earlier quoted context omitted.

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) be…

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 edi…

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.

Re: PipeWire 0.3 – JACK compatibility layer with comparable performance to JACK2

#25

Post by RossBencina »

cycloptic wrote: post #24
RossBencina wrote: post #22

Earlier quoted context omitted.

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 edi…

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…

Thanks for offering to help. I'm okay at the moment. I was referring to other users reporting issues that turn out to be ALSA configuration problems (e.g. on the PortAudio mailing list). Sidenote: the fact that someone needs to offer help is part of the issue that I'm pointing at. Once a driver is installed on Windows or Mac OS I've never heard of someone experiencing misconfiguration of the audio subsystem as a whole.

The main ALSA misconfiguration issue I've personally encountered were not related to the audio drivers per-se, but to codec mixer configuration. It was on RK3399 SBCs from FriendlyArm. In that case I had to read the codec data sheet to work out how to set all the ALSA mixer flags and parameters correctly to get audio routing to send a signal to the output jack.

Re: PipeWire 0.3 – JACK compatibility layer with comparable performance to JACK2

#26

Post by cycloptic »

RossBencina wrote: post #25
cycloptic wrote: post #24

Earlier quoted context omitted.

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…

Thanks for offering to help. I'm okay at the moment. I was referring to other users reporting issues that turn out to be ALSA configuration problems (e.g. on the PortAudio mailing list). Sidenote: the fact that someone needs to offer help is part of the issue that I'm pointing at. Once a driver is installed on Windows or Mac OS I've never heard of someone experiencing misconfiguration of the audio subsystem as a whol…

I'm not sure what larger issue you're pointing at and I don't think it makes sense to chalk this up to anything else; no sound server can magically figure out how to read that data sheet either. A random userspace daemon (that is optional) is just not the right place to put a fix for that. The burden for a fix likely falls on your distro to ship the correct udev rules, but figuring out what those are for all variations of hardware that use that driver is another story. With that who knows, the Windows and Mac driver could actually be doing something strange by default that just happens to work for most users, but isn't worth replicating if someone writing udev rules decides they want to do the "right" thing. See where I'm going with this? It's not just a quick fix, and I don't even know if it's the right one. Some other distro somewhere might even have a different way to do it. If you're really interested to make progress on this, you'll have to ask your distro's audio maintainers.

Re: PipeWire 0.3 – JACK compatibility layer with comparable performance to JACK2

#27

Post by jancsika »

mappu wrote: post #21
cycloptic wrote: post #16

Earlier quoted context omitted.

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?

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 Pi…

> In this case JACK's primary draw over PA/alsalib/whatever is solely the lower latency, for responsiveness in live performances.

I see you included ALSA as a library which you claim wouldn't hit as low a latency as using JACK. Is that what you meant to write? If so, what situation do you have in mind where sound arrives at your ear faster by way of app->JACK->$foo->speaker vs app->ALSA->speaker?

I ask because I'm only familiar with using JACK where $foo = ALSA backend. It stands to reason that JACK-handing-off-to-ALSA cannot possibly achieve a lower round-trip latency than going straight to ALSA. And the round-trip latency measurements I've read to compare those two routes confirm that reasoning.

Re: PipeWire 0.3 – JACK compatibility layer with comparable performance to JACK2

#28

Post by mappu »

jancsika wrote: post #27
mappu wrote: post #21

Earlier quoted context omitted.

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 Pi…

> In this case JACK's primary draw over PA/alsalib/whatever is solely the lower latency, for responsiveness in live performances. I see you included ALSA as a library which you claim wouldn't hit as low a latency as using JACK. Is that what you meant to write? If so, what situation do you have in mind where sound arrives at your ear faster by way of app->JACK->$foo->speaker vs app->ALSA->speaker? I ask because I'm on…

You are correct for ALSA == the kernel driver model.

But using "alsa" as a userspace audio stack has its own latency, dmix in particular. A highly optimized .asoundrc might be competitive.

This feels to me like background knowledge from long ago, but I can't provide any specific source other than anecdotes like https://forum.audacityteam.org/viewtopic.php?p=234235#p23423... .

Re: PipeWire 0.3 – JACK compatibility layer with comparable performance to JACK2

#30

Post by Intermernet »

jcelerier wrote: post #10
misterbishop wrote: post #3

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.

> 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 there... any help appreciated :D

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!
Post reply on HN