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