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
There’s no point in
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.
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.
I kinda explained that in my last post. Thanks for reminding me.
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.
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).
Real-time priority limits are usually stored in
/etc/security/limits.d/. The best option is to add a new file
/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.
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.
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.
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.
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.
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.
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.
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