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.