Amadeus PaulussenDear #linuxaudio friends, what are your thoughts on my dream of a new #pipewire / #wireplumber app? 🤔
https://amadeuspaulussen.com/blog/2026/a-new-pipewire-and-wireplumber-app
caitp
Morten Mosgaard@amadeus what an amazing - and bold - idea! I could see this go in many directions.
I personally only use Helvum, and I rarely ever open it, since Bitwig has native pipewire and other than that, I use Carla to use VST3s on a line in for OBS use.
That being said: If the things you mention are all possible, it would be a crazy strong argument for using Linux for more complex and interesting approaches to audio production.
@amadeus I could also see how this, if build open and with the right approach, could create opportunities for producers of audio interfaces, to make their new complex software mixers, so control the interfaces with - with functions you would never or rarely have on other platforms.
That could especially be exciting for systems like UAD; that could create an even stronger system than their current Universal Console, which could actually make the audio devices usable as full featured live mixers.
@amadeus the idea that you could use your audio interface as a live mixer - instead of using your live mixer as an audio interface - would really be attractive to people doing a lot of live recordings.
I have actually done this with my UAD setup for streams during the lockdowns - but I needed to manually route different channels to an AUX, so I could use physical wires to connect the channels into a masterchannel, where I could have different effects.
@mosgaard I have always viewed the existing PipeWire/WirePlumber apps as kind of proof of concept apps. I always dreamed of a Linux Audio control centre app, a patch bay, a mixing console for all audio and MIDI signals. 🤓
@mosgaard Yesterday, I completely forgot that @fortifieduniverse is already working on a similar vision with his Session Mixer project, see: https://github.com/michaelquigley/sessionmixer. I want to talk to him soon and see if he thinks my wish list could line up with what he has in mind with his project. 🤓
Sandy Corzeta@amadeus Thats a huge list of request. I do agree on some fundamental requirement such as easy internal routing and buffer/sample rate bitdepth profile switching. But to extend it enabling a vst/clap plugin on a system-wide level pipewire config is kinda stretch too much (would burden to maintain, if its not compatible with some 3rd party plug in the future). Not to mention that would be prone to feature-creep.
I'd rather choose they or someone would provide a virtual audio device driver at a kernel level like virMIDI does or ARC Engine from Loopback App on Mac to provide the bus grouping and reroute it to them for the possibility of using realtime effects inside the virtual device. Surely this will need another app to manage that virtual audio device capability. As i see hellvum and qpwgraph is quite suffice to provide the patchbay graph for basic need.
I'd rather choose they or someone would provide a virtual audio device driver at a kernel level like virMIDI does or ARC Engine from Loopback App on Mac to provide the bus grouping and reroute it to them for the possibility of using realtime effects inside the virtual device. Surely this will need another app to manage that virtual audio device capability. As i see hellvum and qpwgraph is quite suffice to provide the patchbay graph for basic need.
@sandycorzeta You might be right, maybe I went toofar. But, you know, I just wrote down what I would love to use. 😜😇
The “plug-in injection” feature in particular could be great for achieving some kind of UAD (and others) workflow for live applications—with more latency, but still convenient and powerful. Not sure if that makes any sense.
dried@amadeus is coppwr on your radar? Some of the config & monitoring stuff might be possible with it, and it might be worth suggesting features there too.
I currently just use qpwgraph for routing and I manually edit the jack buffer size in the config file. Some of the features you've listed would be nice, eg xrun monitoring, but I'd probably only use them in a lightweight tray applet, not a kitchen-sink app. Just my preference.
@dried I looked at it once, but it was too technical for me at the time. 🫣😅 However, given the circumstances, I now need to take a closer look at it. Thanks for mentioning it!
@fortifieduniverse Are you familiar with coppwr?
Fugue State Audio@amadeus Sounds interesting. Most of that isn't anything I feel like I can't live without right now, but a lot of it seems like the kind of thing I would use, and then get so used to having that I *would* be saying I didn't want to live without after a while.
@fstateaudio Thank you for your feedback! 🤓
Michael9@fortifieduniverse I didn’t think about Session Mixer yesterday 🫣—somehow I seem to have filed it away in my tired brain under “Focusrite.” I’m sorry 😞
Do you see me using Session Mixer in the future with the features I am looking for?
I simply had the impulse to write down what I’d like to see in an app like this.
But let’s talk about it soon, okay?
@fortifieduniverse @amadeus uh! Could it work with other class compliant interfaces, like my Zoom H6 or Allen Heath mixer?
@mosgaard @amadeus Yes, the goal would eventually be to support a range of interfaces with different capabilities. What you'll ultimately be able to do with SessionMixer will be determined by what your interface exposes via ALSA.
The Focusrite interfaces just happen to expose all of the internals through ALSA, so it's quite possible to control the internal mixers and routing and such.
Ultimately SessionMixer will also end up managing PipeWire, also.
@fortifieduniverse @amadeus that sounds like a really great approach. I have been a fan of the project all the way, and now even more.
I think it's smart starting with the ALSA part, I presume this means you can route directly from an input to an output (at least that's how I interpreted your posts and Github) without the need to go through Pipewire? If yes, would there be a latency advantage in that?
Pipewire routing is quite easily managed now, so I understand if that's not a priority.
Yes, you can control all of the routing inside the interface with SessionMixer. There is definitely a huge latency advantage in that. That's typically why people want onboard mixing.
Minor thing... ALSA in this case is only used because that's where the internal controls for the interface are exposed. ALSA isn't used to pass audio of any kind... it just provides the mechanism to manage the state of the hardware.
@fortifieduniverse @amadeus I’m afraid we enter technical things I’m not completely sure I understand.
So sorry if this is just repeating.
Can it be expected that sound can be internally routed in all class compliant interfaces?
And if yes: What does it take for SessionMixer to start supporting a specific audio interface?
@fortifieduniverse @amadeus thanks!
So to make internal routering (if the hardware design allows), the system needs to get a usable driver for that specific unit?
Because I could see this be REALLY awesome with my Allen Heath QU-SB. It has internal routing using the Allan Heart app, which kind of sucks (atleast to me).
@fortifieduniverse @mosgaard
I’m not sure how mature your vision for a universal SessionMixer is. I’ve looked at the roadmap, but I’d love to learn more.
Personally, I’d like to identify the best concepts and workflows from coppwr, qpwgraph, Cable, helvum, Loopback, UAD Console, RME TotalMix, and Focusrite Control; distill them together with our own ideas; and design UI/UX sketches for a PipeWire app so good that distros will want to ship it by default. 😎
The vision is more mature than what's on that roadmap board. It's just not well documented yet.
I think we have similar goals, but we may or may not be headed in the same direction with the approach. We can certainly discuss...
@fortifieduniverse Yeah, let's talk about it. 🤓
Chris Mills@amadeus I agree that this all sounds quite nice to have, but I make minimal use of routing at this time as I don't have an audio interface and everything is "in the box".
I wonder if it might help to have it shown why these are things we should want to have?
@ambientspace These are certainly features that you would mainly use if you had one or more audio interfaces connected to your computer. For example, in situations like that you might want to create virtual headphone mixes with effects for recording artists and then record dry signals in the DAW. Things like that. That aside, I envisage such an app being easily approachable for less complex circumstances too.
Michael Gale@amadeus my very limited experience with pipewire is the cli leaves a bit to be desired, so i say yes!
MyLoFy@amadeus
Are you aware of Cable? It already combines a lot of tools: https://github.com/magillos/Cable
Are you aware of Cable? It already combines a lot of tools: https://github.com/magillos/Cable
@MyLoFy Yes, I know Cable. Thanks. There are a number of tools available, but none of them handle the set of tasks and features in a way that aligns with how I (subjectively) think they should be approached. Plus, most of the available options have a rather minimalist, rough UX, if that makes any sense.
DaforLynx VGM@amadeus agree on the ability to freely create virtual nodes and aggregate devices - exactly what i had to write a script for to activate on every login. I didn't know configuring per-device samplerate and bit depth was possible. Volume mixer would also be awesome. And ESPECIALLY saving and loading configurations and having them persist even when nodes go offline *so I don't have to keep disconnecting things from my speaker output*.
But uh ... Hope this goes somewhere!
But uh ... Hope this goes somewhere!
@DaforLynx One day soon! 🙏
Solemarc@amadeus I think anything that makes pipework better, even if it doesn't affect me is a good thing.
Currently, in order to toggle mute in my system I fire off a keyboard event for the special keyboard button that toggles audio mute.
I tried doing it through the pipewire cli first but gave up and did it this way instead.
FediVerseExplorer
Michael Mathy@amadeus still needs to read the article but beside that, there is more and more content on your site more and more frequently. Will be really nice to have a RSS feed 😀
DRMR@amadeus This almost sounds like raysession but with pipewire features added.
Having a kind of "session management" where you can store both connections and application state (that NSM for JACK already provides and which pipewire supports) would be pretty important in a studio setting.
@dreamer Yes, like that, and also with a mixer like in RME's TotalMix or UAD's Console. You know what I mean?
@amadeus Sounds like total overkill. Not something I would need or use (except for the application blocksize and samplerate settings)
@dreamer (1/3)
I see it differently. 😜 In my view, Linux Audio needs a universal, easy-to-use yet professional audio management application—something comparable to the proprietary macOS/Windows tools provided by major audio interface vendors like UA, RME, or Focusrite, but built around PipeWire/WirePlumber and compatible with practically any (including multiple) USB-CC or otherwise Linux compatible audio interfaces.
I see it differently. 😜 In my view, Linux Audio needs a universal, easy-to-use yet professional audio management application—something comparable to the proprietary macOS/Windows tools provided by major audio interface vendors like UA, RME, or Focusrite, but built around PipeWire/WirePlumber and compatible with practically any (including multiple) USB-CC or otherwise Linux compatible audio interfaces.
@amadeus I don't see the relation to hardware interfaces though. This is fundamentally a completely different problem to solve.
Also if you start your design with a list of feature creep then you will never create a functioning product ;)
So find the most pressing issues to solve (like config level things that are currently hard) and start there!
I would like a modern replacement for pavucontrol made for pipewire ;)
@dreamer Thanks for the good advice! Makes total sense. At the very least, the features in my wishlist need to be prioritized, and there are certainly quite a few priority 2 and 3 items on my list. 🫣😜
Doesn't that already exist? See: https://github.com/saivert/pwvucontrol
@mosgaard Pipewire already supports jack. "native pipewire" would actually mean less features.
@dreamer That's interesting you say that, thanks for sharing!
As new to Linux, all my audio-trouble disappeared when I started using Bitwig, which also gave me - internally - more features than other DAWs I tried.
That could of course be a question about how the DAW is wired, but I took it as a clear sign that Pipewire was a step forward - especially for me as a "new to Linux" user.
@mosgaard When you run a DAW as the central hub for an audio system you usually don't need pipewire or jack at all. You can just run alsa and have the DAW take control of everything.
For me that's a huge limitation and the poor integration with Linux MIDI is my biggest gripe with Bitwig ;)
@dreamer I really appreciate you taking the time to explain this, thanks!
I just tried to open a project in Bitwig and switch the driver model to ALSA, and so far, that also works really well for me on my system. So what I experienced could just be other DAWs not working properly regarding driver model on the distros I have tried.
Could you elaborate on the limitations with MIDI? Is it general to LINUX or depended on driver model?
@mosgaard Bitwig requires "direct access" to hardware devices which means these devices are subsequently blocked from other applications on the system. By extension Bitwig cannot communicate with other software MIDI applications either.
There is a tedious workaround using virtual midi ports, but this has bad UX and doesn't always work.
@dreamer ah, ok. I understand!
This is not something I have encountered since I don’t have the need to use midi other places. But I could see this becoming a problem for some, especially on a live setting.
Is it your impression it’s intentional?
@mosgaard I have spoken to one of the devs over the years, it was originally a design choice, but not necessarily deliberate. I thought it had to do with hardware integration, but that was not the case.
For proper Linux MIDI integration I prefer Qtractor and Ardour ;)
(but their MIDI sequencing isn't as good/fun)
If Bitwig ever decides to bring the same level of integration they have with audio (jack and pipewire) to MIDI then I'll have a good incentive to upgrade my license!
@dreamer When you say that the hardware support is a different problem to solve, do you mean it's an individual problem for each vendor to solve, i.e. they need to offer their software for Linux as well?
@dreamer (2/3)
An app that makes the hidden powers of modern Linux Audio attractive and approachable not only for musicians, producers, and engineers switching to Linux for serious audio workflows, but also for everyday Linux users who simply want to set up reliable, predictable and reproducible audio setups comfortably and without having to wrestle with hard-to-understand, fiddly, or fragile tooling (no disrespect to existing tools!)—or resort to the CLI and scripts.
An app that makes the hidden powers of modern Linux Audio attractive and approachable not only for musicians, producers, and engineers switching to Linux for serious audio workflows, but also for everyday Linux users who simply want to set up reliable, predictable and reproducible audio setups comfortably and without having to wrestle with hard-to-understand, fiddly, or fragile tooling (no disrespect to existing tools!)—or resort to the CLI and scripts.
@dreamer (3/3)
In short: a polished app with a modern UI and musician-friendly UX that bridges the gap between "it is powerful if you know how" and "it is powerful and magically easy to use.", if that makes any sense. 😊
In short: a polished app with a modern UI and musician-friendly UX that bridges the gap between "it is powerful if you know how" and "it is powerful and magically easy to use.", if that makes any sense. 😊