I'll start off by thanking the hard work that has gone into qpwgraph, it has made huge progress and it's a great tool.
However there is one thing that still makes it unusable for pro audio: the lack of persistent audio connections across session restarts. In QPWGraph, the Exclusive/Activate buttons are unreliable and the functionality is very hit or miss, which makes it essentially as if it wasn't there.
Musicians absolutely need a way to set their routing, and have it not change afterwards for whatever reason. Linux audio has come a long way and, in 2026, linux has become a real option for doing pro work with audio and live visuals of all sorts. We have companies putting out linux native versions of their products whcih run even better than the Windows/Mac versions, and when native linux versions are not available, the community has made ports using Wine etc that have really opened up the space for linux to become a true outlet for pro creatives in the audio and visuals fields.
There is one real, big, obvious problem when it comes to pro audio: audio routing persistence. If musicians have to spend 15 minutes every time they need to start working it is a non-starter. If I have to worry every time I am going to play live whether the routing is going to be messed up and I will have to troubleshoot in front of my audience then I will use Windows/Mac. If opening any new app or moving anything in the audio space adds / changes the routing, linux becomes a non-viable tool for pro audio. It is that big. The bottleneck is there, and it is a huge, huge problem for linux really finally becoming a reliable, professional OS for pro audio.
What we need is a very standard audio routing solution where I set my routing, click save, and that's it. Nothing else gets added, nothing else gets removed, nothing else gets moved around, ever. Period. This is a very standard thing to have in Windows/Mac audio since at least the late 90s. The lack of this very basic behavior in linux (pipewire, jack) is legit a linux pro-audio killer.
I am not knowledgeable enough to understand the technical details of why linux behaves so differently than the other two operating systems. I've heard it has to do with device ID's, but I might be totally wrong. But the reality is this has been a non-issue in the digital music world for more than 30 years at this point.
So let me state the problem a bit more systematically:
PROBLEM: Linux musicians set up their routing using tools like QJackCtl, QPWGraph, RaySession. Save the patchbay/session, whatever its called. Close sessions. Reopen sessions, and the routing changes in the most annoying and unusable way. Users need to come up with silly workarounds or waste time rerouting. In QPWGraph specifically, "Activate" and "Exclusive" don't fully work as expected, as is attested by the multiple online posts about this issue of frustrated musicians trying to switch to linux only to face this breakpoint.
SOLUTION: When musicians hit save routing, that's it. It remains in place, it persists, it doesn't change, or add or remove anything until the user manually does it. This should be an out-of-the-box behavior, click-save-and-forget with no silly and convoluted workarounds involving config files and code and scripts that get in the way and quite literally prevent musicians and audio designers to get to work (and prevent the adoption of less technical users that just want to be creative and not have their OS get in the way).
I cannot overstate enough how much of an adoption-killer this apparently silly tactical problem is, and how much of an inflection point it is for the wide-spread adoption of linux as a real, serious, production-ready platform for musicians, audio designers, performers, etc. It is bewildering (and frustrating) to many of us as veteran linux users to see the entire ecosystem move forward where we've always wanted it to go, just for it to fail in the most trivial and silly part of the music-making process.
Like I said at the beginning, there is nothing but gratitude from me and many many others to devs who have made all of this possible. I hope this comes across as an honest and hopefully kind wake-up call about a glaring issue that (for reasons beyond my understanding) has not been addressed by it seems any of the main GUIs and backends available for routing audio in linux. I hope it's just an honest dev oversight in some way and not a deep technical reason for this. If the latter, then linux might probably just have to continue relegated to being a second-tier option for musicians, being used by amateur musicians instead of proper, professional creatives who build amazing things and make money with it.
Thanks.
re. persistent connections to QPWGraph...
critical or not, there's been a writing on the wall all over these years: the so called linux-audio ecosystem gives you (a LOT of) options to the user, even more so to pro-audio folk; this plethora of options is both a blessing and a curse.
now, let's be reasonable about this and to cut a long story short, let's put it in this way of A MAJOR ADVICE to all users, no matter they're pros or else:
please read this straight:
DO NOT RUN MORE THAN ONE AND ONLY ONE PATCHBAY OR SESSION MANAGER AT ANY ONE TIME
follow this closely, as known as the Highlander rule:
you can only have one
in qpwgraph parlance, having "Activate"d and even more dreadful "Exclusive" patchbay profile maybe be a curse and disaster if you rely on your DAW or session manager (eg. RaySession/NSM) to recall connections on their own.
or to be in the safe side, leave activated/exclusive on the qpwgraph patchbay profile only those nodes that are NOT possibly managed by your pro-audio stuff (eg. web-browsers, media-players, etc.; in case of doubt, use the Patchbay > Manage... super-powers ;)
you'be been advised.
;)
re. persistent connections to QPWGraph...
not sure where you got the idea that I have multiple session managers at the same time, because I don't. this is not the issue, it's the deeper issue with the very simple, obvious, solved-in-the-90s problem of having persistent connections in linux.
like I said we are grateful for your work and other devs, but the answer you provided is not helpful because it just... doesn't really say anything. why is it so difficult to get a proper answer about this very important issue? not that hard, its either:
A. it's impossible to do because of the way linux handles X and Y.
B. yes it is possible to do by doing first A, then B, but it requires you to do a, b and c for it to work.
C. i do not know if it's possible to do.
this would be useful instead of an esoteric response that requires deeper knowledge and context to be deciphered. don't want to be rude but this is really a deal breaker for many and it is frustrating to have to chase threads all over the internet and esoteric responses from the people who actually could help us solve this.
re. it's CRITICAL
And all this without even considering the problem that the kernel is responsible for identifying devices.
My MIDI controller is a Keystation61-MK3, possibly one of the most popular. It has two MIDI outputs, one general and one exclusively for controllers. I always have to manually reset the general output because it connects to the controller output by default.
Apparently, this is a kernel bug that has already been fixed in versions higher than 6.8 (it affects all types of devices, not just mine).
What I mean by this is that a GNU/Linux operating system is the result of combining many independent developments, each with its own origins, and most of them are entirely altruistic.
It's not like Windows or macOS, where there's a unified development path.
That's why the persistence problem was solved in those systems back in the 90s, but not yet in Linux.
However, that unified development path does exist. Where? Those responsible for creating the specific operating system for a specific purpose (music, education, science) are the ones who create it. Well, in this case, if it's a problem that's essential to you, you are responsible for it.
You must find, build, or contribute the necessary knowledge and resources to solve it.
It's that simple. Freedom demands responsibility.
And once you manage to solve it, if you wish, you can share your solution with others.
re. multiple session managers...
you think you don't
most if not in all pipewire installations out there you always have one session manager running all the time but hidden: wireplumber
for instance, if any one of the pinned connections on qpwgraph clashes with some wireplumber rule, then you have a problem: qpwgraph can't and won't help you there re. persistent connections. you'll have to fix it at the wireplumber side (now you run: there's prolly nothing in life more esoteric than just that:))
so, anyway, the most rightful answer above is therefore B. always; however, whether doing the A, B and a, b or c actually depends on each user case and configuration; proverbial YMMV.
as said on the previous answer rather esoteric for you, please:
qpwgraph may give you some tools to help you on the rescue and mitigation for a general problem (persistent connections) but surely is not, cannot, won't ever be, the one-stop and definitive solution. sorry.
hyu.
cheers
Add new comment