Pipewire will complain about not being able to reach rtkit at startup, but it will still run without it. You just wont get pipewire automatically talking to rtkit to elevate realtime priority of audio programs. However, that shouldn't matter unless you are looking at getting to very low latency levels.

Note if you check pipewire will also complain about missing xdg_desktop_portal, which is another runtime dep pipewire uses with the portal module. However, pipewire will still run without that too (needed for screen sharing AFAIK).

@adcdam

I haven't tried running pipewire-pulse separately like that, I just launch it with pipewire by uncommenting pipewire-pulse in the pipewire.conf file. This causes pipewire to also start pipewire-pulse (and pipewire-media-session) all when you start pipewire.

Check if DBUS_SESSION_BUS_ADDRESS is set properly when you launch pipewire. It gets set by dbus-run-session or dbus-launch, in display manager scripts and xinit respectively. Also note that if you're using startx then it may not be getting set right in the stock slackware script. See this post and the couple following ones from earlier in this thread: https://www.linuxquestions.org/quest...ml#post6194651

Excuse me, BUT I am under impression that PipeWire wants to talk with RtKit via DBUS to raise its own realtime priority, not of the client programs.

And let's do NOT think on black and white: Professional Audio vs. Hill Billy's Audio, because there are also many shades of gray.

After all, the PipeWire is an Audio/Video server, and I believe that the processing of video streams is also heavy affected by the realtime priority of PipeWire daemon, because they requires even more processing power.

The user may be not interested by running a DAW, while looking for ways to make his/her video streams more fluid, without framing.

Hence, probably is always better for the PipeWire server to have a greater realtime priority.

I confess I'm a bit puzzled... I did not try PipeWire but I doubt, as AlienBOB seems to be suggesting, it could replace JACK in a DAW setup. While it is true that Ardour has its own routing capabilities, many applications use JACk for routing (from the non-daw packages, to many others) and, as far as I understand, PipeWire lacks these capabilities -- am I wrong?

What puzzles me is alse the need of rtkit to escalate rt privileges. I came to know rtkit about a year ago when I was trying to achieve low latency on a pre-PAM slackware with AlienBOB's DAW packages. At that time for applications like JACK, ardour and others needing real time priority to run with low latency, "setcap" could do the job, but not with PulseAudio. Like PipeWire it indeed requires rtkit for escalating the rt priority, but I found out that rt_limits was tricking it to believe it could escalate without the need of rtkit. But that should NOT be needed in a PAM system. Now PusleAudio acquires rt priority without rtkit and I really do not understand why PipeWire should not.

I do not have strong arguments against PulseAudio, systemd or other stuff written by Lennart, but I'm not really able to understand the need of rtkit in a PAM system (yes, Lennart wrote rtkit too). There is this interesting thread where Paul Davis (the author of JACK and ardour) is explaining why:

https://news.ycombinator.com/item?id=21926545

Just my 2 cents.

Don't forget Paul Davis is also responsible for LADSPA and LV2. The man is actually Epic. I've long wondered if he is any relation to the reclusive genius audio engineer Don Davis.

I'm only reporting what I have observed in testing out pipewire, both as a pulseaudio and jack replacement. What I have seen is that pipewire will have a scheduled higher priority, along with audio programs that start and connect to the pipewire jack server. E.g If I start ardour and connect to the jack server provided with pipewire, I see ardour scheduled with rtprio, same with hydrogen, and they are set with SCHED_RR, rather than SCHED_FIFO, which is what rtkit does by default. That leads me to believe that rtkit is indeed involved, no?

Unfortunately running a DAW on linux seems to historically been complicated and full of misinformation. I am hopeful that pipewire simplifies things somewhat, but it does seem to take more work to get audio running at live performance latency levels (e.g. 10ms or less round trip). And yes pipewire is also a video server and I have largely been ignoring that. Probably because I crossed this topic over with Eric's blog about DAW work, which is my area of interest and why I have been mentioning it. Not trying to be black or white, just sticking to what I have experience with.

If you have jack installed you can build pipewire against it, which builds pipewire's version of the jack libraries. Once these libraries are symlinked properly, pipewire appears as a jack server to jack aware programs. E.g. If I have pipewire running, start ardour and select jack, ardour reports that jack is already running and can connect to it. Ardour has its own routing capability, which when running on a jack server just uses the jack connection graph. Pipewire does not have a standalone connection graph tool but existing jack tools like carla or qjackctl can connect to the pipewire jack server and you can route with the graph tool in those applications. Hope that helps

From my testing you still need to adjust capabilities through PAM for DAW work (e.g. unlimited memory, and rtprio). I think rtkit was used just because it was used with pulseaudio IMO. Like that forum thread says, rtkit is a convenience tool to raise priorities in a "safe" way. Here it's used for pipewire and some of its client programs. The rtirq shell script is another convenience tool to raise irq priorities. You can get by without them I suppose, but it's nice not having to do things manually.

Part of the problem seems to be a lack of official documentation and what exists for pipewire is scattered across difference sources. I'm just reporting what I have found by using it mostly, in hopes that other people who want to try it can test it out and report here too if they want. Disclaimer: I am not an expert, I just want to do audio work in a consistently well performing system.

1 members found this post helpful.

This method has been working for me:

Go to /etc/asound.conf

and comment the 2 lines for pulseaudio

save/exit
and do:

#pkill pulseaudio

finally reboot

config (unmute alsamixer)
that should do it.

if something is missing, I install it with sbotools

sbofind alsa
sboinstall whatever is missing

usually, this is not necessary