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.