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