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.
This is pretty intriguing - is there a public roadmap for these Live-like features ?
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.
Slowly I'm trying to get https://ossia.io there... any help appreciated :D
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...
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.
BTW from my perspective there already is a major project driving a revival of open source audio, and that project is called JUCE [0].
(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.
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.
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... .
A laughable pipe dream.
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.
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.
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.
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.
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).
Edit: sidenote is there any software works with a mixtrax3