Pipewire-jack providing JACK system-wide: Issues with JACK client visibility and using the hardware in native pipewire
Hi! When providing pipewire-jack's JACK libraries system-wide (as replacement for e.g. jack2), I'm running into odd issues with the visibility of JACK clients in the graph and the accessibility of my audio interface by pipewire in general.
Previous setup
With an ld.so.conf override and libs in /usr/lib/pipewire-0.3/libjack* I was able to have multiple JACK clients in the audio graph (e.g. carla, custom sinks, mpd). Pipewire would both recognize the device as one of its own devices and also expose it as a device in the JACK graph.
New setup
When providing pipewire's JACK libs system-wide (i.e. in /usr/lib/libjack*) and without the ld.so.conf override, pipewire itself still sees the device in pw-cli list-objects
and declares it as a native interface (see pw-cli-output.log), but native pipewire clients (e.g. mpd) are unable to use it (this was a red herring, as the client auto-selected some other node to stream to and then never changed back to anything else and I didn't notice in pavucontrol).
I'm able to set/unset the "Pro Audio" profile for my device using pavucontrol, but it doesn't change anything (for the issue below).
With native JACK clients it becomes even weirder, as the clients have varying visibility. E.g. patchage is able to see other clients in the graph, carla is unable to do so and only exposes its own input and output (but I can't connect it to the hardware!). Meanwhile qjackctl and ardour can also see the graph and other clients in it. I am also unable to use null-sinks to connect a chromium instance with my hardware now.
Are additional configurations required when using the pipewire provided JACK libraries system-wide? When configuring the build I was under the assumption, that using the option to configure the library location is used to be able to provide this use-case. Is there something I am missing?