[cycloptic]

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

[PaulDavisThe1st]

To be fair, as the original author of JACK and the lead author of one the main DAWs on Linux, we no longer encourage the use of JACK with Ardour.

JACK is an exceptional powerful tool (if I do say so myself) but it is overkill for the majority (maybe even the vast majority) of users. We try to encourage most Ardour users to use its builtin ALSA audio/MIDI I/O support rather than JACK these days.

[cycloptic]

I am a JACK/Ardour user and I still use application-application routing regularly to do other things. There are some workflows that are hard to do inside any given DAW, not just Ardour. This results in me having to run multiple DAWs at once, so running Ardour directly on ALSA won't work. You're right though that this situation is overkill -- I want to help fix some of these issues but Ardour is a large project and is difficult for me to start contributing to at the moment. Porting JACK-native programs over into audio plugins also takes time. Unfortunately this means I will probably be stuck on JACK for a while.

But all that is beside the point anyway. I still stand by my statement that a new DAW should use the JACK API, for compatibility purposes. I would change my mind about this if it ever comes to the point where JACK support is removed from Ardour and the other major DAWs. Take that as you will.

[bwanab]

Paul, first of all, let me thank you for the great software you’re developed. As a long time JACK user, Can you point me to a more detailed write up on why it is overkill?

[PaulDavisThe1st]

There's no such writeup.

But look - most people don't actually want to connect multiple applications together to make music. Most people don't actually want to move audio between applications at all. As we get more and more (reasonably) good plugins available on Linux, the "monolithic" approach - do it all inside one program (e.g. a DAW or something a bit like it) is easier for most people (no complex state management) and closer to their pre-existing mental models.

If you do need/want to connect multiple applications together, then sure, JACK is great and better than more or less any other possible alternative for that purpose.

But most people don't want to do that, and increasingly do not need to either.

[johnr2]

> do it all inside one program (e.g. a DAW or something a bit like it) is easier for most people (no complex state management) and closer to their pre-existing mental models.

This may be a generational thing. As someone who learned recording in traditional analogue studios, I find a modular approach using JACK to be much closer to my own mental model.

[mxmilkb]

With the greatest of respect, maybe, going forward, it would be best for clarity to include a caveat along with your "JACK is probably overkill" statements that you are taking about users who don't require (or might be interested in it) inter-app audio/MIDI/CV routing?

[cjsthompson]

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]

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]

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.

[jancsika]

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

[mappu]

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

[cycloptic]

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

[mxmilkb]

If only JUCE supported the open LV2 plugin format..

(And opening up projects in Projucer and saving out something wasn't an all to commonly required build step)

I would encourage interested folk to check out DPF and/or come hang out in #lad and #lv2 on Freenode.

https://github.com/DISTRHO/DPF

[cycloptic]

Right, I actually avoid using JUCE for my personal projects for this reason :) But it has resulted in a ton of plugins being available that would otherwise not have had native Linux support.

[zokula]

>PipeWire is meant to be a complete replacement for not only JACK, but also PulseAudio.

A laughable pipe dream.