No module "libpipewire-module-rt" was found on Fedora Silverblue

[jmaibaum]

I am running on Fedora Silverblue 36, and I wanted to look into why Ardour's performance was so bad (frequent xruns even when nothing else was running).

I found [E][00686.466973][ impl-module.c: 264 pw_context_load_module()] No module "libpipewire-module-rt" was found in the output:

$ LANG= flatpak run --env=PIPEWIRE_DEBUG=3 org.ardour.Ardour 
WARNING: Could not check your glib-2.0 for mutex locking atomic operations.

Ardour6.9.0 (built using 6.9 and GCC version 11.3.0)
Ardour: [INFO]: Your system is configured to limit Ardour to 524288 open files
Ardour: [INFO]: Loading system configuration file /app/etc/ardour6/system_config
Ardour: [INFO]: Loading user configuration file /var/home/jm/.var/app/org.ardour.Ardour/config/ardour6/config
Ardour: [INFO]: CPU vendor: GenuineIntel
Ardour: [INFO]: AVX-capable processor
Ardour: [INFO]: AVX with FMA capable processor
Ardour: [INFO]: CPU brand: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
Ardour: [INFO]: Using AVX and FMA optimized routines
Ardour: [INFO]: Loading plugin meta data file /app/share/ardour6/plugin_metadata/plugin_tags
Ardour: [INFO]: Loading plugin statistics file /var/home/jm/.var/app/org.ardour.Ardour/config/ardour6/plugin_metadata/plugin_stats
[I][00686.401606][      pipewire.c:  571 pw_init()] version 0.3.35
Cannot xinstall SIGPIPE error handler
Ardour: [INFO]: Loading default ui configuration file /app/etc/ardour6/default_ui_config
Ardour: [INFO]: Loading user ui configuration file /var/home/jm/.var/app/org.ardour.Ardour/config/ardour6/ui_config
Ardour: [INFO]: Loading 452 MIDI patches from /app/share/ardour6/patchfiles
Gtk-Message: 13:56:33.607: Failed to load module "canberra-gtk-module"
Ardour: [INFO]: Loading color file /app/share/ardour6/themes/dark-ardour.colors
Ardour: [INFO]: Loading ui configuration file /app/etc/ardour6/clearlooks.rc
Ardour: [INFO]: Loading bindings from /app/etc/ardour6/ardour.keys
Loading ui configuration file /app/etc/ardour6/clearlooks.rc
[I][00686.465535][ pipewire-jack.c: 2941 jack_client_open()] jack-client 0x55579af7b390: open 'ardourprobe' options:1
[I][00686.465688][          conf.c:  326 conf_load()] config 0x55579af88360: loading config '/usr/share/pipewire/jack.conf'
[I][00686.465794][       context.c:  384 pw_context_new()] context 0x55579af87f30: parsed context.properties section
[I][00686.466839][       context.c:  478 pw_context_new()] context 0x55579af87f30: parsed 1 context.spa-libs items
[E][00686.466973][   impl-module.c:  264 pw_context_load_module()] No module "libpipewire-module-rt" was found
[I][00686.466993][          conf.c:  408 load_module()] config 0x55579af87f30: skipping unavailable module libpipewire-module-rt
[...]

Is this expected?

The module is installed:

$ ls -l /usr/lib64/pipewire-0.3/*module-rt*
-rwxr-xr-x. 2 root root 32552  1. Jan 1970  /usr/lib64/pipewire-0.3/libpipewire-module-rtkit.so
-rwxr-xr-x. 2 root root 32544  1. Jan 1970  /usr/lib64/pipewire-0.3/libpipewire-module-rt.so

[jmaibaum]

I have also reported this with the pipewire development team: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2556

[hfiguiere]

pipewire is shipped by the runtime (freedesktop-sdk). So if something is missing, it's in the sdk.

[hfiguiere]

I recommend using the ALSA backend anyway.

[hfiguiere]

Just to clarify, Ardour doesn't use pipewire. But when using JACK the pipewire-jack backend is used. Not certain of how that thing is supposed to work. And it seemed to want to use org.freedesktop.RealtimeKit1 DBus to access realtimekit (it used to crash without).

[pinkflames]

From what I know, Flatpaks (due to sandboxing) are not supported by RTKit anyway, so the only way to use realtime inside a Flatpak is via RLIMITs, which of course need to be set up on the host side via /etc/security/limits.d/ (and require a reboot to apply).

[hfiguiere]

There is a rtkit portal though so there might be a solution.

[pinkflames]

I'm not that familiar with portals and the issue with RTKit but my understanding is that RTKit is not aware of namespaces and while it does receive the Flatpak's request, it gets confused by the fact that the request pertains to a client that is not running in the same namespace as the daemon (most likely due to PID or user namespace).

[hfiguiere]

Here is what's in the Platform/SDK:

$ find /usr -name \*pipewire\*
/usr/lib/x86_64-linux-gnu/libpipewire-0.3.so.0
/usr/lib/x86_64-linux-gnu/libpipewire-0.3.so.0.335.0
/usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_ctl_pipewire.so
/usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_pipewire.so
/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstpipewire.so
/usr/lib/x86_64-linux-gnu/pipewire-0.3
/usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-adapter.so
/usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-client-device.so
/usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-client-node.so
/usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-loopback.so
/usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-metadata.so
/usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-protocol-native.so
/usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-rtkit.so
/usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-session-manager.so
/usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-spa-device-factory.so
/usr/share/pipewire
/usr/share/pipewire/pipewire-pulse.conf
/usr/share/pipewire/pipewire.conf

The conf:

    # Uses RTKit to boost the data thread priority.
    {   name = libpipewire-module-rtkit
        args = {
            #nice.level   = -11
            #rt.prio      = 88
            #rt.time.soft = 2000000
            #rt.time.hard = 2000000
        }
        flags = [ ifexists nofail ]
    }

    # Set thread priorities without using RTKit.
    #{   name = libpipewire-module-rt
    #    args = {
    #        nice.level   = -11
    #        rt.prio      = 88
    #        rt.time.soft = 2000000
    #        rt.time.hard = 2000000
    #    }
    #    flags = [ ifexists nofail ]
    #}

So it seems the module is disabled in favour of rtkit, which has a portal (albeit I don't know if pipewire uses it)

[pinkflames]

I think you're looking at the wrong file: pw-jack would use pipewire/jack.conf file, which probably defaults to module-rt for 0.3.36.

Also there is still only host PW daemon, so the portal is irrelevant for PW itself. As for the JACK client using the compatibility libjack.so, no idea but, as I said, I don't believe RTKit itself supports namespace sandboxed clients (but I could be wrong).

[hfiguiere]

Notice how there is no libpipewire-module-rt.so. So whatever is the config, it's not there.

[hfiguiere]

so you volunteer to file the issue with the freedesktop-sdk?

[hfiguiere]

Filed it https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1455

[hfiguiere]

It will be in freedesktop 22.08.

[jmaibaum]

Saw you note in the FDO tracker, thanks for making sure that the modules will be there in the upcoming FDO runtime.

However, I am not yet sure what I as a user am supposed to do in order to configure RLIMITS/priorities correctly.

I understand that my previous assumptions were based on too few knowledge about pipewire on the host vs in the runtime, but I am left puzzled what config has to go where?

[pinkflames]

It's really up to the each distro to provide their users with a pipewire group which has upstream recommended RLIMITs set on it, so that from end-user perspective they just need to add themselves to the pipewire group and reboot to benefit from professional realtime support.

You can of course create your own /etc/security/limits.d/50-custom.conf file and directly give your user(s) or group(s) realtime you want but it would be best solved at distro level with a pipewire group.

[hfiguiere]

This was fixed with #41