The pipewire devs themselves do not recommend it:
Edit: either I posted this in the wrong thread or my comment was moved out of context. Someone was asking if the 1.0 release marks the time to make Ardour use the pipewire API directly.
We are?
Look, PipeWire is a great achievement, I’m a (forced) Convert… But that same example could be done with one less sound server on a properly set up JACK(jackdbus)/Pulse or JACK/Pulse/pajackconnect system. I understand in the greater Linux world PipeWire is necessary and long desired, but routing anything to anywhere has been possible on Linux even with JACK and alsa-loopback even before PulseAudio arrived and chewed up all the scenery. Back then some Distros provided Firefox compiled with the JACK backend which would have made the scenario above even simpler! With all due respect this is not living in the future, it’s another way of doing what was possible to a large extent in various ways in the past…
In truth to completely set up PipeWire for Pro Audio is at least as difficult as setting up JACK/Pulse was/is, in fact Ubuntu Studio, KXStudio and AV Linux pretty much had the whole thing demystified out of the box so it wasn’t even a hurdle to jump over any more. So it is what it is… it really doesn’t have a lot of new tricks under it’s sleeve and it’s not trivial to set up in an optimized system… It may be progress but it is not revolutionary in any way…
4 Likes
To be precise; what the PW devs recommend is to still use Pulse and JACK APIs when writing audio software.
At least for the time being.
2 Likes
Maybe not from a pure audio POV but PW is more than just audio routing.
The article GenGen linked to is well worth reading.
1 Like
True 
I’m new to the audio world, but I’m a sysadmin by trade, so the thing I’m marveling at here is the fact that this is working at all over like three distinct API boundaries. I’m (dimly) aware that the whole signal routing part is old hat to a lot of people here.
Regarding what you said about configuration: That’s all correct and I have nothing to add.
1 Like
Now to give some credit on the other side… I’ve just minted a test ISO with PipeWire for the first time and it was a bit of a build config nightmare to assemble and link everything but I can say now that I have the recipe if major Distributions took a couple of extra steps and just did this THEN Pipewire would truly come across with it’s World Domination hat firmly in place and there would essentially be no further need for ‘Studio’ Distros…
I don’t understand why both pipewire-pulse and pipewire-jack can’t just be both fully configured in all mainline Distros by default… it’s not like they collide or cause any problems… Pulse stuff connects to the Pulse pins and JACK stuff to the JACK pins. I can now cold boot a Live ISO and without ANY intervention fire up Ardour, Reaper and Mixbus 32C and connect to JACK and start recording, Reaper defaults to JACK anyway so it launches ready for battle… … Only optional step is the metadata adjustments which I have a UI for now… So well done PipeWire!
Now if Ardour would simply scan $HOME/.vst by default (again extra Reaper points for doing this by default) my joy (and work) could be complete… Yes there is no VST2 folder spec but everybody knows that’s where they go… 
4 Likes
Would mind sharing these configuration steps?
Hi!
I was talking more in the context of an ISO building recipe, which is sort of like compiling a program where you have lay out the steps and configuration in a script, then build it and hope everything ends up in the right place, this is also on system build with no jackd or jackdbus and only the barest PulseAudio requirements so that may differ from an installed system.
As I recall you are using Debian Sid so I would follow the Debian 12 instructions here:
https://wiki.debian.org/PipeWire
In my experience the trickiest part is that getting PipeWire’s JACK to work invisibly like ‘old’ JACK still requires the manual linking instructions from the Debian 11 ‘For JACK’ section and the file location is wrong for Debian 12 so here are the correct instructions (note the ‘#’ means as Root or with sudo, don’t paste it with the commands):
Create this empty file (may not be necessary but it doesn’t do any harm):
# touch /usr/share/pipewire/media-session.d/with-jack
Either run JACK clients using the pw-jack wrapper, or copy:
# cp /usr/share/doc/pipewire/examples/ld.so.conf.d/pipewire-jack-*.conf /etc/ld.so.conf.d/
And run:
# ldconfig
1 Like
This sounds promising!
I’m tempted to try it again but, apart from puzzling out how to configure things just right in pro-audio mode, what broke for me last time was connecting Renoise to Ardour via both MIDI (clock and MMC) and audio.
I could connect them, but one or the other app would just crash within seconds.
Do you have any existing idea as to how well this works now? Obviously, the canonical answer comes from testing it; I’m just hoping somebody’s already spent those hours
After you get it all installed there is also the tricky part that currently there is no easy way to change parameters easily. When using jackd I would typically use QJackCtl and hit “Stop” to stop the jackd server, load up a configuration file or manually change sample rate, buffer size, MIDI configuration, etc., then hit “Start” button to get jackd running again.
With pipewire there are some CLI tools to request changes, but I have not yet found a convenience tool which has a configuration window to select available options, and an “Apply” button (I think pipewire does not have the same concept of stop and start like jackd).
Possibly there are tools available that I have not found yet. I’m not particularly averse to CLI, I have started jackd from CLI plenty, but it can get tedious typing out options, or having to edit shell scripts for different configurations when I already have Ardour and several other GUI programs running anyway.
1 Like
Note that media-session is deprecated and is replaced by wireplumber
I realize that, I still follow all the Wiki steps to get it to work as I expect, perhaps Step 1 is not necessary any more, but in the end it all works and I think there is no harm in Step 1 even if the former session manager is deprecated…
Yep true, There are several on github and I made my own YAD one, here’s an early prototype (requires YAD to be installed). Of course it may need some edits to work on other systems. Note in another PipeWire thread somebody improved it but I don’t have time to track it down right now…
#!/bin/bash
#Simple Yad frontend for pipewire-metadata (first draft)
#broken out from AVLinux PipeWire Tools
buffer=\
`yad\
--entry\
--licon="textfield"\
--height=128\
--width=400\
--button="Continue":0\
--center\
--image="pipewire-app"\
--title="PipeWire Metadata Quantum Settings"\
--window-icon="pipewire"\
--text="<b>Enter new buffer size.</b>\n Suggested values are:\n 64|128|256|512|1024|2048"\
--text-align=left`
pw-metadata -n settings 0 clock.force-quantum $buffer
samplerate=\
`yad\
--entry\
--licon="textfield"\
--height=128\
--width=400\
--button="Continue":0\
--center\
--image="pipewire-app"\
--title="PipeWire Metadata Sample Rate Settings"\
--window-icon="pipewire"\
--text="<b>Enter new sample rate.</b>\n Suggested values are:\n 44100|48000|88200|96000"\
--text-align=left`
pw-metadata -n settings 0 clock.force-rate $samplerate
pw-metadata -n settings 2>&1 |\
`yad\
--text-info\
--text="<b>Review your new pw-metadata 'clock.force' settings.</b>"\
--fontname="Red Hat Text Medium"\
--image="pipewire-app"\
--image-on-top\
--center\
--width=540\
--height=260\
--button="Done":0\
--window-icon="pipewire"\
--title="Current PipeWire Metadata Settings"`\
exit
No, you don’t need to stop and start it like jackd. The concept with Pipewire is for Applications to choose the sample rate and buffer. Obviously, this conflicts slightly with how everyone uses QJackCtl to choose settings for all the applications to obey. In lieu of an application choosing the settings, there is a default setting. There are applications to change setting instantly but they only do it temporarily. Upon next restart, they will back how they were.
To make a more permanent change, you can make a text file called anythingyoulike.conf in the folder ~/.config/pipewire/pipewire.conf.d
As an example, if you want the default buffer to be 512 then the contents of the file would look be
context.properties = {
default.clock.quantum = 512
}
This will override the setting that comes with pipewire normally. (you do need to restart pipewire to use that)
Ideally, an application in the future would be able to change these files as well as dynamically change the variables. Also, there is an option to force all application to use a setting but it seems like something that might mess you up if you set it, forget about and then applications start putting in the options to have their own and you’re wondering why it doesn’t work
Now that you mention that I saw your previous post, and have been meaning to make time to check it out. I had forgotten about that until you mentioned it again.
I have the modified version by bobu posted here:
Simple Pipewire 'pw-metadata' UI
That is great for desktop applications, but that is not how you (usually) want audio production software to run. The JACK API is designed around all applications using not only the same sample rate but the same buffer size. I expect that the pipewire-jack implementation will enforce that same restriction, while the Pulse API implementation would not.
Thanks for tracking that down @ccaudle ! the @bobu version is much improved and more compact, I’m pretty limited in my skills… 
From: Continuing the jack/pipewire debate... - Page 17 - LinuxMusicians
The PipeWire buffer size in the graph is the same for all clients. Client can each make a suggestion about their preferred latency and PipeWire will configure the minimum latency of those suggestions. PipeWire does not attempt to have a different buffer size per client or do anything fancy to group buffers or wakeups.
If a client asks 64 sample buffers and another 1024, the graph is using 64 sample buffers and the one asking for 1024 gets woken up every 64 samples as well. If it can’t produce 64 samples, it can do its own buffering (like what the ALSA plugin and pulseaudio emulation do by placing a ringbuffer inbetween the app and the pipewire graph). But JACK clients all run at the same buffer size in the graph, just like JACK
1 Like
I hope that will change in the future. One the many strengths of CoreAudio is that each client can choose its own buffer size (though I think there are conditions where it may not get precisely that size).
Here’s a pretty good overview over how everything is playing together by the author of the Linux kernel modules that add support for recent Focusrite audio interfaces.
2 Likes
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.