Pipewire regression, midi bridge missing

[QuickFastly]

Describe the bug

I use Carla (flatpak) to process audio on my system, split across several virtual sinks created with pipewire and LV2 plugins. I also use a USB midi controller to control the volume of each sink independently, among other things, through the JACK midi bridge. To do this, I run Carla with the audio driver set to JACK and the process mode set to multiple clients.

I have been running Bazzite version 41.20250331 for a long time now. I had no problems with this setup on that version, or any version prior.

After updating Bazzite, the midi bridge disappeared in Carla. All my sinks still exist, I can still load plugins fine, and even the routing still works when I load everything up, it's just the midi bridge missing. There were also always two sources called BLE MIDI (in and out) that I never did anything with, but those are gone too. If I switch the audio driver to JACK with ALSA-MIDI, I can see the midi devices again, but because there is no multiple clients process mode that way, I can't see my virtual sinks.

This problem started on the very first update after 41.20250331, so I rolled back and waited for another update, hoping that would solve the problem. It hasn't.

Screenshots from 42.20250425

And from 41.20250331

What did you expect to happen?

I expected nothing to change, and for my Carla setup to continue working the same as it always has, with working midi.

Output of rpm-ostree status

● ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable
                   Digest: sha256:40b77b67f68eafad230e48f453be5aeb4ed42cb0996a43d6e8245e3a3ab752f1
                  Version: 41.20250331 (2025-03-31T05:06:20Z)
          LayeredPackages: mullvad-vpn
            LocalPackages: lact-0.6.0-0.x86_64
                   Pinned: yes

  ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable
                   Digest: sha256:f7f0ff512e894cf5ab0db7a316a102c5b48b8d3f90302a3c0c73ffd1180aefaf
                  Version: 42.20250425 (2025-04-25T16:41:11Z)
          LayeredPackages: mullvad-vpn
            LocalPackages: lact-0.6.0-0.x86_64

Hardware

PC: Gigabyte X570 Aorus Xtreme, Ryzen 9 5950X, 32GB RAM, Radeon 6900XT
Relevant USB devices: ZOOM UAC-2 (audio interface), AKAI LPD8 (midi controller)

Extra information or context

I haven't seen any signs of errors or issues with pipewire itself, hence why I'm posting this issue here instead of there. I found two issues on the pipewire gitlab that might be related, but both are closed as solved already.

For fun, I tried installing qpwgraph (flatpak) to see if anything would be different there, and I don't understand how or why it happened, but midi devices were visible in it after a reboot. They were shown as pipewire devices though, not JACK, and they were not functional no matter how I routed them, with or without Carla running.

[CheckYourFax]

This is probably the relevant commit:
a6212bd

@KyleGospo Any idea?

[QuickFastly]

Small update. Thinking (hoping) it could have been a kernel issue, I tried 42.20250430 today. No change. It's definitely a pipewire problem.

[jistr]

I hit the same thing with Fedora Silverblue 42, same symptoms: Carla and Ardour don't see MIDI devices. qpwgraph does see them but even if i connect them there, they don't work.

With pw-mididump or jack_midi_dump running in a container (not a flatpak) i managed to get MIDI events shown. However, nothing running in a flatpak runtime seems to receive MIDI input correctly, no matter what i try.

I wonder if this could be due to the host OS having pipewire 1.4 which, AFAIU, includes a major switch in how MIDI is handled (MIDI 2.0 and UMP), while the flatpak runtime org.freedesktop.Platform/x86_64/24.08 has older pipewire 1.2 (if i dug up the sources correctly).

[CheckYourFax]

If silverblue shows the same, I would open a topic on the Fedora forums or make a direct bug report on the red hat bugtracker. Probably your best course of action if its an upstream issue.

For the other thing: flatpaks generally use flatpak libraries and drivers. This means flatpak uses flatpak pipewire libraries.

This counts for pretty much anything in the userspace, even for things like Mesa. This is also one of the reasons why we don't support flatpak Steam.

You could try layering the apps you use, to see if its a flatpak issue. Do this with rpm-ostree install < packagename >

[jistr]

I just managed to google another report of the same thing, the person reporting that using Ardour installed directly rather than from flatpak fixed their issue:

https://www.reddit.com/r/linuxaudio/comments/1k6gxup/comment/moujwb0/

Not sure if pipewire 1.2 client is meant to talk flawlessly with pipewire 1.4 server, other than that i think all components are working "as expected" and this issue is just uncovering a problem with the concept of flatpaks in general. Many times having different libs on the host vs. in the app works fine, but sometimes it doesn't, and that's where traditional package management has an edge (albeit it has a bunch of other problems). This is 2nd time i've hit a similar issue with pipewire version difference between host and flatpak runtime causing a breakage...

[QuickFastly]

Layering Carla has indeed worked around my issue. I can live with that. Kind of disappointing to find out it's a flatpak problem, since I've only ever had one other issue with flatpak applications and it was much less annoying than this one, but I'll close this issue since it's not caused by Bazzite.

[jistr]

FWIW i created an issue in PipeWire, requesting backwards compatibility within some span of client/server versions, to prevent breakage of flatpaks: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4712