[misterbishop]

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.

[PaulDavisThe1st]

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]

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

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.

[jcelerier]

> 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

[Intermernet]

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]

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

[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

[zokula]

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

A laughable pipe dream.

[johnr2]

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

[scns]

Check out Bitwig

[paulie_a]

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]

Bitwig was created by Ableton employees.

[zokula]

I wouldn't be too quick to assume that Pipewire will be the default anywhere.