It looks a bit high level as a replacement for jack, but it’s promising. Currently kxstudio with cadence bridges is working fine for me, which might be a similar approach. The problem is more PulseAudio itself, on one hand, and that someone should implement jack-like api functionality or audio threading at kernel level so there is professional audio for android and other platforms too, once and for all. There is an initiative to have audio in standard c++
I don’t think there is a ‘permanent problem of jack integration for audio’ on linux.
The problem can be running pulseaudio and jack in the same time. I would blame pulseaudio for that, if there has a blame to make. Or blame audio integration on linux in general.
For better integration between pulseaudio and jack, sure, pipewire might be a solution for that. Most serious people doing audio, might not even want that type of integration with desktop audio though and want to have the lowest possible latency. Quite some SC users are in that group one would guess. Then jack is still the way to go I think.
I’d go a step further: Running Pulse and JACK simultaneously already works beautifully, 100% reliably – from that standpoint, integration is already excellent, and has been for some time.
The problem is documentation, installation, configuration.
Every first time user starts JACK, loses audio in Firefox, and a few “oh s—”'s later might have found a few websites with contradictory advice. The first web hit, How use PulseAudio and JACK? | JACK Audio Connection Kit, recommends primarily “Option 1: don’t use PulseAudio with JACK” and then proceeds to shunt integration advice off to a second page – considering that the user has arrived at this page specifically to find out how to integrate the two, this is spectacularly condescending (in a way that seems rather in keeping with JACK’s developer culture, actually).
… which is all totally unnecessary for a feature that works.
In any case, when the developer attitude is “you shouldn’t want this,” of course they will provide no tools to automate the hybrid PA-JACK setup. So then it’s “omg this is so hard” instead of “works out of the box” (and we should accept this because JACK is for professionals and it isn’t a toy yadda yadda yadda).
Would be nicer with one backend that handles everything, sure.
I still went back to my old jack/pulseaudio setup though, as I was not able to get stable 256 sample buffersize on 48k. However, I expect this to be solved shortly. The development tempo is insane, and issues are being fixed at an alarming rate.
Give it another year, and my guess is that jack and pipewire will be indistinguishable.
I agree that pipewire seems very promising, and it is already, at least in my Linux noob experience, more stable than the jack and pulse combo when it comes to switching sound cards on the fly and things like that.
Pipewire has seen a pretty intense period of development lately and it is now more than capable for SuperCollider usage. I switched to it recently and it works nicely (and now allows for example to code SuperCollider over bluetooth headphones!!).
I hope that pipewire will become the norm for new linux distributions because it really is much more simple to use than the different layers we are all accustomed to use right now. It doesn’t solve every problem, especially for some niche use cases like SC and creative / musical applications, but the first time I got it to work, it felt like it was a new beginning for audio on Linux.
Many thanks for all the people that worked so hard on pipewire.
Pipewire is actually another layer above Pulseaudio and Jack actually. And I’m not sure if it’s simple. It started as a system to be able to run videos in a sandbox?
Yesterday, I removed Pulseaudio from my system, and now I’m wondering, why did I have it installed actually all those years? Most applications use Alsa or Jack nowadays right? I’ve a onboard + external soundcard setup. One for pulseaudio (now Alsa) and one for Jack.