There’s no point in chowning pipewire to another user/group, you’d hose your setup that way. You can, however, run processes with any of the groups of which you’re a member, by using the sg tool.
1 Like
I guess your right.
after a chat in #pipewire @OFTC irc server
seems like /etc/security/limits.d/25-pw-rlimits.conf that containig
@pipewire - rtprio 95
@pipewire - nice -19
@pipewire - memlock 4194304
should just stay like is
- since limits.d does not have anything with the pipewire process other than it allows groups gain access to the rtprio stuff
When you log in to your computer pipewire process will start as your login user.
If that user is added to pipewire group, pipewire will get the realtime priority through your username thats in the group that have been given access in the limits.d config.
Kind of conclusion
When I did changed to my loginusername in /etc/security/limits.d/25-pw-rlimits.conf I gained access directly and not through the pipewire group (that I did not have in my system) where I suddenly had a monster of a computer that,
- now run with a buffersize 128 without xruns , even buffersize 64 I can do small projects like 1-2 miditracks and 4-5 audio tracks. I got a i7 1 gen cpu with 12GB ram. ssd 128GB. and a usb focusrite scarlett 2 gen 18i20. A bufersize 128 for me is ok, since under 10ms delay I have no issues. I even did a session i mixbus32cv9 with 53 tracks with a buffersize 128. When mixing I dont need fast response , only when perform and need effects like compressor or eq stuff. Since my audio card does not come with that.
cheers.
1 Like
It’s a good idea to leave that file alone and simply create the pipewire group instead, because when/if your distribution decides to update the file in the future, you won’t automatically benefit from the changes.
2 Likes
I kinda explained that in my last post. Thanks for reminding me.
an update.
I have made a group named pipewire
sudo addgroup --system pipewire
sudo usermod -aG pipewire myusername
restarted computer and its still working like a charm.
1 Like
I think runiq meant that it is better to copy the file to the etc folder and change it there instead of changing the original file (which is vulnerable to being changed with updates). 
See:
RLIMITs
Real-time priority limits are usually stored in /etc/security/limits.conf and /etc/security/limits.d/. The best option is to add a new file 95-pipewire.conf in /etc/security/limits.d/ with this content:
# Default limits for users of pipewire
@pipewire - rtprio 95
@pipewire - nice -19
@pipewire - memlock 4194304
Then add your user to the PipeWire group so that you can use these priorities.
3 Likes
Thank you, yes, that’s what I meant. In my distribution the file in /etc came directly with Pipewire, that’s why I didn’t mention copying it over.
2 Likes
Also, in case it bites anybody: adding your userid to a group does not affect your current shell (or desktop session): you need to log out and log back in again after making changes to groups for those changes to take effect.
3 Likes
you’re right, I did the same. Suddenly I can also work with 256 Buff with 35 CH with Plugin in Ardor.
A miracle has happened.
Thank you!
1 Like
it should be possible to also restart the systemd service from the user account since it is defined in user-context.
systemctl --user |grep -i pipewire
you can override pipewire daemon-launch settings in ~/.config/systemd/user – by using “systemctl cat systemd-unit-name > _systemd_unit-name” (it has to be the same filename, then you can edit this unit file, and use daemon-reload, and restart it)
this way, there’s no need to apply changes by re-logging-in (unless you’re still making group changes for the logged-in user)
I know I might sound a little studious, but there’s also a safer/easier way for users to prevent dbus daemons from launching in their account:
(ln -s /dev/null _name_of_systemd_unit ; systemctl --user daemon-reload)
the symlink is made in ~/.config/systemd/user
it’s imho not safe to make changes in /etc/ld.so.conf.d/, as it can cause stalls unexpected elsewhere.
interested thread nevertheless - I also think I am learning a few things as well regarding pipewire as it is still relatively new and still somewhat confusing as how to properly administer it.
I also completely missed that this development work was occurring, but just saw it mentioned in an interview with Wim Tayman in Fedora online magazine:
“We’re focusing on getting AES67 working instead, which works on more readily available hardware. We’ve added support for PTP clocks in PipeWire and the RTP sender and receivers. We’ve had success integrating Dante devices with AES67 with PipeWire.”
The “instead” referred to also adding AVB support which is not working yet, but apparently with Pipewire 1.0 you can directly access AES67 devices.
3 Likes
wow, this is some thread. Some background: I’ve been using JACK with Kubuntu/Ubuntu Studio/KX Studio since about 2018. It took a few months to get it tuned the first time - on 18.04. It got progressively better/easier going to 20.04 and 22.04). As of now, it all does whatever I want and need (granted, I’m just a beginner). So I don’t want to f–k with it.
Currently, my DAW (Ardour 7.5/JACK and it’s awesome!) is running on Kubuntu 22.04 LTS. My laptop is on 23.10 so I can check out PW (plugged in audio interface, confirmed some stuff worked but haven’t installed Ardour or done anything yet other than editing some files in Audacity).
Now note that I haven’t (yet) read this entire thread. But … I’m still somewhat vague about this whole thing. Does /anybody/ have a link to a blog post, youtube vid, TedX seminar that can finally lay all this down?
Can I still use Catia? My laptop has some PW knockoff connection manager with a horrible GUI. Assuming it’s still “any IO to any IO” I’m just gonna end up with squiggles of fluorescent green lines going everywhere.
Can I still have Firefox streaming audio while I run my guitar thru Rakarrack, into Ardour and out thru the interface?
I guess the answer is to commit to at least several hours of diving in. After several hours of backups, iso downloads, boot disk creating, etc etc.
Oh, the fun we had.
22.04 LTS is supported until 2027 so if you’re happy with your current DAW setup you should probably keep it as is until then.
PipeWire is like PulseAudio and JACK combined, so anything that has worked previously with either system will continue to work with PW, including Catia.
The only caveat is that you may have to start JACK programs with something like pw-jack -p 128 path-to-catia-or-ardour-or-rackarrak depending on how your system is set up (I haven’t yet figured out the magic needed to get Ardour to automatically connect to PW’s JACK interface).
Yes, you can have Firefox streaming though PW’s Pulse module while at the same time having Rak going through the JACK module. Firefox automatically connects to the Pulse module, so you don’t have to do anything particular there.
3 Likes
That should not be needed in a typical setup. The pw-jack program was for forcing programs to use the pipewire JACK libraries when they started as an intermediate step while you had pipewire-jack and jackd installed on the same system. If you are working on pipewire and need to go back and forth to jackd to compare behavior, or if you are investigating behavior of both to determine whether there are any notable differences in behavior you might still need that. Most distributions would setup either only pipewire-jack or only jackd, in which case you do not need to use pw-jack to force selection of a particular libjack.so because there will be only one installed.
1 Like
Yeah, the magic needed was to run stow -D -d /opt -t /usr/local jack2-1.9.22 , to remove the symlinks I had from /opt/jack2-1.9.22 to /usr/local, and then to add /usr/local/lib/x86_64-linux-gnu/pipewire-0.3/jack/ to /etc/ld.so.conf.d/00-pipewire-jack.conf , to make sure the PW JACK libs were found.
I have self compiled versions of jack2 and pipewire installed in /opt and symlinked to /usr/local using the stow command, so distro installs of these programs probably have this more or less correct set up from the start
What I want to do is run the audio output from Firefox through Rakarrack. Or even more fun, route my mic input through Rakarrack before it goes to my work video conference.
2 Likes
Not Rakarrack, but here’s Firefox routed via qpwgraph though Guitarix, on the “Rock You Like A Hurricane” setting.
For some reason it didn’t make Rick Astley sound like Klaus Meine; I’ll report that bug to the guitarix folks.
3 Likes
This is amazing to me. One is Pulseaudio, the other Jack, and all of it is going through Pipewire.
We’re living in the goddamn future, people
1 Like
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