I am struggling to configure pipewire to use in real time.
I want to play a guitar throught guitarix with a ~10 ms latency (256 samples / 48000 Hz).
I copied the configuration files from /usr/share/pipewire to ~/.conf/pipewire.
I removed ~/.conf/pipewire/client.conf and renamed client-rt.conf to client.conf.
I replaced all the 44100 occurences by 48000 and every 1024 occurences by 256.
I added my user name to the pipewire group.
I restarted my PC (the systemctl --user restart pipewire.service doesn’t seems to work fine wrt configuration files).
After that. I start my guitarix session via rayesssion…
I clearly hear that the latency corresponds to a 1024 samples buffer, not a 256 samples one …
When I checked via pw-top the latency, there is still a 1024 buffer on the alsa side.
Does somebody succeeded to configure pipewire to be useable in real time ?
It seems that alsa clients currently (it’s not in 0.3.33) do not have RT priority. So you could either add the patch to 0.3.33 or wait for the next release.
Thanks a lot for this link. I will check ASAP.
The documentation is quite obscure on whether we need to add a configuration file for pipewire into /etc/security/limits.d, like is done with jack.
There is a pipewire group, but I don’t see the benefit of add this file yet
$ sudo usermod -a -G realtime ycollet
Not sure if log out & log in is enough, reboot to make sure.
On the yabridge discord there have been several discussions about pipewire and proper realtime settings. You could join at yabridge and ask what people use.
Then there is this neat script by Robbert, the developer of yabridge, which takes away high priority/realtime scheduling of apps so it does not interfere with your DAW. I could not find the location so pasting here.
#!/usr/bin/env bash
#
# script from Robbert Yabridge
#
# Some applications like to spawn high priority realtime threads. This can cause
# latency spikes during DAW usage.
thread_blacklist_re='^(webrtc_audio_mo|InotifyEventThr)$'
process_blacklist_re='^/usr/lib/(firefox|signal-)'
# To make it easier to see what's going on and which threads we're going to
# reschedule, we'll print all realtime threads with their thread names and the
# first part of their command, and we'll mark the threads we're going to
# reschedule.
realtime_threads=$(ps hxH -u "$USER" -o tid:30,rtprio:30,comm:30,command |
# HACK: Since thread names can contain spaces and ps doesn't have a way to
# specify a delimiter, we'll hack around this a bit by making every
# every column fixed width and then manually adding tabs. This would
# have been neater with some proper parsing, but, oh well...
# We'll also truncate the last column for readability's sake.
sed -E 's/^(.{30}) /\1\t/;
s/(\t.{30}) /\1\t/;
s/(\t.{30}) /\1\t/;
s/ +//g;
s/(\t[^ ]+)( [^\t]+)?$/\1/' |
awk -F$'\t' '($2 >= 5) {
if ($3 ~ THREAD_RE || $4 ~ PROCESS_RE) { printf "x\t" } else { printf " \t" }
print $2 "\t" $1 "\t" $3 "\t" $4;
}' THREAD_RE="$thread_blacklist_re" PROCESS_RE="$process_blacklist_re" |
column -ts$'\t')
need_rescheduling=$(echo "$realtime_threads" | awk '$1 == "x" { print $3 }')
echo "$realtime_threads"
if [[ -z $need_rescheduling ]]; then
echo -e "\nNothing to do here, modify the blacklists if needed."
else
echo -e "\nSetting all marked threads to SCHED_OTHER..."
echo "$need_rescheduling" | xargs --no-run-if-empty -n1 chrt -po 0
fi
Yes, I just saw that in the patch you sent.
And thanks a lot for the realtime-setup package to install + the script.
I was stuck with my habit of manually tweaking the script installed by jack in /etc/secucity/limits.d
So, I am still struggling.
I think the problem is mostly related to the setting of the main audio rate. Something is not catching up correctly this main audio rate. Maybe the problem lies in the USB audio interface. There’s a ticket on pipewire / gitlab related to such a problem with a Focusrite Scarlett.
So, I must stick to the default audio rate: 44700 Hz if I want to limit the problems I’ve got.
Next step: trying the realtime audio with the pipewire jack. Currently, I am still using the “original” Jack server.
Here’s a recording, at 44.7 Khz and with the default Jack.
Everything is fine.
If I change the main audio rate to 48 Khz, the audio of the recorded video (via simplescreenrecorder) is one step below the original (certainly in a ratio of 44.7 / 48 …).
I don’t know yet.
I have new problems with pipewire. The first connection with jack produces a crackling noise. I need to stop jack and restart jack to have a clean sound. And this, everytime I restart my PC.
So, I am waiting fora new pipewire release to check the realtime jack thing.
So, I performed new tests with Fedora 36. It’s better, but I am still not able to use pipewire with a low latency. There are xruns when I tried with 10ms latency. So, I switched back to jack.
I still have problems with kernel-5.17 and Focusrite sound cards. It’s getting better too, but there are still problems.
I reinstalled a new PC with Fedora 37 and decided to give it another try to pipewire Jack.
Video made on Fedora 37 with OBS Studio.
Guitarix / TuxGuitar / Non Mixer / Ray Session and pipewire jack configured to use 256 samples buffer and 48 kHz sample rate.
There are still some Xruns from time to time but the situation has greatly improved when I compare the last try I made.
I used a 5.10 RT kernel. I will try with a recent one, maybe pipewire will be more confortable with a recent RT kernel.
The pipewire configuration is the standard one.
Good to hear you made some progress. I never used an RT kernel, I just use the latest 6.x kernel in the Fedora updates repo. I use 44100 instead of 48000 in pipewire which resulted in less issues in my DAW (Bitwig).
So, I tested the latest official 6.1 kernel from Fedora 37 with “preempt=full” added as a boot parameter a I was able to reach a perfect pipewire behaviour with jack and a 127 samples buffer size. Just 2 XRuns triggered by tuxguitar while opening some guitarpro files. Nothing totally abnormal, this was already like that with standard jack !
