Mumble 1.4.230 is missing PipeWire as audio subsystem

[Gert-dev]

Problem

The release notes for 1.4.230 mention that it has PipeWire support on the following line:

Added: Native support for PipeWire (#4970)

In the past, I've taken this for a test drive using mumble-git from the AUR on Arch Linux, and it worked well, but, now that the stable version is released, it seems to be missing as option from the Flatpak version.

Steps To Reproduce

1. Open the settings window.
2. Go to Audio Input settings.
3. Click open the audio subsystem dropdown; ALSA, JACK and PulseAudio are listed, but not PipeWire.

Expected Result / Possible Solutions

PipeWire is listed as an available option.

Additional Info

This could well be an upstream issue with Mumble itself, as it dynamically detects which subsystems are available; for example, if you take away the PulseAudio Flatpak permission, it won't show PulseAudio, as expected. It could also be tha PipeWire requires an additional Flatpak permission. If it's an upstream issue, I'll be happy to report it there.

I'd compare it with the stable Mumble from the Arch Linux repos, but 1.4.230 is not packaged yet officially. I can test it against the native version as soon as it's available in case it helps.

• Version: 1.4.230
• Operating System / Distribution: Arch Linux x86-64
• Desktop Environment: GNOME 41.3
• Kernel Version: 5.16.0

Thanks for maintaining this!

[jbruechert]

My flatpak version doesn't seem to have a permission for pipewire, but it's possible that it's just too old. I'm already using Pipewire too though, but through pipewire-pulse, and that works.

If you know the name of the permission (and it doesn't break older flatpak versions), I can add it of course.

Btw, Pipewire at least seems to be installed in the flatpak, as mumble already uses the pipewire libraries to speak to JACK.

[Gert-dev]

Indeed, I also use PipeWire to emulate PulseAudio and it works fine using the PulseAudio subsystem. Mumble 1.4.230 should now also support using PipeWire directly, though, which may result in lower CPU usage.

I've been looking around a bit, and I don't know enough about flatpaks, but does Flathub automatically build applications from source based on the configuration provided here? If so, it might be necessary to ensure PipeWire is available in the build environment, since I think Mumble checks if PipeWire is available as build time dependency (the AUR package also added it).

I've been staring at how the Flatpak-ed PulseEffects does it, and it looks like it directly includes PipeWire, but it may be a different case altogether. Another thing they do is add --filesystem=xdg-run/pipewire-0:ro (I can confirm that this isn't sufficient, though).

It could well be that the Flatpak permissions are not at fault, but that Mumble is looking for the libraries in the wrong places or doing an incorrect check to see if it is supported, though.

[jbruechert]

I've been looking around a bit, and I don't know enough about flatpaks, but does Flathub automatically build applications from source based on the configuration provided here?

Yes, the application is built from source in an Sdk that is the same for all apps, freedesktop-sdk. I'm pretty sure that already includes PipeWire, that's why JACK support successfully uses it.

Maybe the PipeWire we have in the flatpak is too old though.

[Gert-dev]

Good to know. I did some digging around the subsystem source, but can't immediately seem to find anything that does an "is supported" check here.

The original PR (mumble-voip/mumble#4970) mentions it was tested with PipeWire 0.3.26; I don't know which version is part of the Flatpak. In any case, the build seems to enable PipeWire by default if the libraries exist.

Mumble prints some info pertaining to PulseAudio and JACK on startup, including JACK 3.0.0.0 (using PipeWire 0.3.35) from libjack.so.0, but no messages regarding the PipeWire subsystem itself.

EDIT: Maybe pinging davidebeatrici might help, since he added the subsystem in Mumble. Hi @davidebeatrici, this project packages Mumble as a Flatpak (sandboxed app), and PipeWire doesn't seem to be listed as subsystem. Is there a minimum version requirement for PipeWire or something specific that Mumble checks for before enabling the subsystem?

[davidebeatrici]

0.3

[Gert-dev]

I'd compare it with the stable Mumble from the Arch Linux repos, but 1.4.230 is not packaged yet officially. I can test it against the native version as soon as it's available in case it helps.

I tested Mumble 1.4.230 from the official Arch repositories today, now that it's packaged, and PipeWire is indeed exposed as subsystem for input and output.

I'm not familiar enough with Flatpak, but some digging implies that the latest FreeDesktop runtime is on PipeWire >= 0.3.40 - though I'm not sure what version org.kde.Platform 5.15-21.08 is based on (I doubt it will have a much older version, though).

[jbruechert]

5.15-21.08 is based on the freedesktop runtime 21.08

[Gert-dev]

I did some digging into the Mumble source code and the world of Flatpaks and I think this may be a Mumble issue. We already verified that PipeWire 3.35.0 is available in the runtime, and I verified that the PipeWire subsystem in Mumble tries to initialize in PipeWireSystem::PipeWireSystem, but it then proceeds to scan for SO names, doesn't find any of those names, and then bails a couple lines further.

@jbbgameich Before I report this upstream, do you have any idea how I can check what the proper SO names are inside the Flatpak base runtime? Since I now figured out how to build Mumble in a Flatpak myself, I can test changing the affected code until it works and then upstream a patch (and this can be fixed in the Flatpak here by targeting the upstream commit fixing it).

EDIT: Nevermind, found it and fixed it. It picks up PipeWire now (in the runtime it's called libpipewire-0.3.so.0, which needs to be scanned for as well). There's still something else wrong where it doesn't receive any microphone input nor plays anything on the output; it works fine in the native version, and no errors are printed. I'll do some more digging to see if I can pinpoint that issue as well.

[jbruechert]

Thanks for investigating! Did you already propose the fix upstream?

[Gert-dev]

I did now!

[Gert-dev]

I also managed to fix the audio input and output not working 🎉 , see also #20.

To fix it permanently in the Flatpak, we'll either have to wait for the next bugfix release once the fix is merged, or this Flatpak could be updated to target the commit from the PR - it should be relatively risk-free since the only improvements included in master this branch is based on are build and documentation improvements, with the exception of mumble-voip/mumble@5a3f678. The downside is the version might suddenly be shown as 1.5.0 in the app, since it was already bumped in master.

[jbruechert]

If the patch is relatively simple, I can just apply it on top of the stable release without pulling in the other chages. Thanks for fixing it upstream!

[Gert-dev]

I tested #21 and everything seems to work. I'll close this, thanks!