Realtime priorities for JACK vs. Pipewire?

Ask Fedora
, , ,
1

The priority limit for JACK realtime threads is 70:

# /etc/security/limits.d/95-jack.conf
@jackuser - rtprio 70
@jackuser - memlock 4194304

@pulse-rt - rtprio 20
@pulse-rt - nice -20

While Pipewire realtime threads have a priority limit of 95:

# /etc/security/limits.d/25-pw-rlimits.conf
@pipewire   - rtprio  95
@pipewire   - nice    -19
@pipewire   - memlock 4194304

Is there a reason for this discrepancy? My mediocre Google-Fu has found that Fedora changed its priority scheme with the Fedora 17 release, but I couldn’t find out anything else about that apart from this email.

Has Fedora decided to change things back to a more ‘traditional’ scheme since? Are Pipewire thread priorities too high? Could that lead to issues with priority inversion? I’m trying to set up my system for low latency audio and I’m not sure what to do anymore…

Edit: I just checked the thread priorities of Pipewire and JACK realtime threads as well. Pipewire’s realtime thread gets rtprio 88, while JACK’s gets 60. Is that on purpose?

JACK’s:

$ ps -p 109009 -Lo tid,class,pri,rtprio,command                                                                              
    TID CLS PRI RTPRIO COMMAND
 109009 TS   19      - jackd --realtime -dalsa -dhw:0 -r48000 -p512 -n2
 109023 TS   19      - jackd --realtime -dalsa -dhw:0 -r48000 -p512 -n2
 109024 TS   19      - jackd --realtime -dalsa -dhw:0 -r48000 -p512 -n2
 109025 FF   60     20 jackd --realtime -dalsa -dhw:0 -r48000 -p512 -n2
 109026 TS   19      - jackd --realtime -dalsa -dhw:0 -r48000 -p512 -n2

Pipewire’s:

$ ps -p 4453 -Lo tid,class,pri,rtprio,command
    TID CLS PRI RTPRIO COMMAND
   4453 TS   30      - /usr/bin/pipewire
   4460 FF  128     88 /usr/bin/pipewire
1 Like
2

Dumb question, isn’t pipewire a replacement for jack?
Is it expected to have jack running in a pipwire world?

3

Not a dumb question! Yeah, it kind of is expected that Pipewire will subsume both Pulse and JACK. It’s backward compatible with the APIs of both—Pipewire has a JACK-compatible library that it uses whenever a program wants to talk to the JACK API. However, you can start JACK manually too, which is what I did (in a toolbox container).

1 Like
4

You can even start JACK with jackdbus (use the DBus option in qjackctl, for example) and PipeWire will become a JACK client automatically, by default. This is handy if you have a FireWire device that is not (yet) supported in PipeWire or maybe you have something that only works with JACK…

2 Likes
5

The answer to the question why the priorities don’t match is simply because I didn’t know about this (and I didn’t even check… I could have…)

This should be rectified, there is no reason why the priorities should be different. For now you can configure the priorities in the config files (check the rt.prio variables for server and client).

I also just pushed a change to make things more configurable (meson: add options to set server and client RT priority (f1a6fabb) · Commits · PipeWire / pipewire · GitLab). My plan is to restore the same priorities as JACK in future build in Fedora.

3 Likes
6

Ah, the man himself—didn’t know you were also on the packaging team. Thanks for making this configurable! :slight_smile:

1 Like