Flatpak packaging – current status and next steps (community input wanted)

[vicrodh]

Flatpak status – quick community check

Sorry this is my first post here, but I want to be transparent about the current state of the Flatpak package and get your input before moving forward.

Flatpak was added to make QBZ easier to install and more visible. In practice, it has become the most problematic packaging format for the project.

Current reality

• No reliable PipeWire bit-perfect playback
  The Flatpak sandbox prevents proper control of PipeWire sample rates, which directly conflicts with QBZ’s core goal.

• Inconsistent device and cast detection
  Some things that work fine in native packages fail or behave unpredictably in Flatpak.

• Extra maintenance cost
  Every audio or device-related feature has to be evaluated separately for Flatpak, often with workarounds, warnings, or documentation.

This is not a Flatpak bug — it’s a limitation of the sandbox model when dealing with low-level audio.

What “freezing Flatpak” means (to avoid confusion)

By freezing Flatpak I mean:

• Temporarily stop publishing new Flatpak builds
• Keep focusing on native packages (AppImage / .deb / .rpm) as first-class
• Revisit Flatpak later if the project or its constraints change

This is different from “publishing Flatpak as-is”.

What do you think?

Please vote on one of the options below:

1. Freeze Flatpak
   Stop publishing Flatpak builds for now and focus on core stability and features.

2. Keep publishing Flatpak as-is
   Continue releasing Flatpak builds alongside others, accepting the sandbox limitations and without special focus.

3. Actively try to improve Flatpak support
   Invest time in Flatpak-specific fixes and workarounds, even if it slows overall development and success is not guaranteed.

Thanks for the feedback.

[tbelway]

I'd like to address a few points:

1. No reliable PipeWire bit-perfect playback
   I was able to get perfect playback by passthrough, not issues.
2. Inconsistent device and cast detection
   Sure, it'll be a learning curve, but realistically with immutable OSes flatpak is the future.
3. Extra maintenance cost
   Not really, because you can just use flatseal to passthrough USB and etc.

Right now is a bad time, but I'd love to contribute on the devops end of this project, I've been wanting to learn flatpak anyway. And under the hood, it's just a container after all...

I'd be more than happy to test and report back on the flatpak issues too, so you can freely use the same code for all package formats.

[vicrodh]

Wow, that’s a really interesting finding. None of my tests across 5 base different distros (6 considering Rpi for aarch64) and two DACs ever behaved like that. I did test Fedora, but it honestly never crossed my mind to try Silverblue, the lord of the flatpaks 💍

This pretty much confirms that it’s highly system-dependent. At the end of the day, the Flatpak itself can only do so much, and for now the safest thing on my side is to keep the warning that it may or may not work, just to avoid making technical promises I can’t fully control. I’m definitely not ruling out spending more time on this later, but right now my focus is on fixing broader issues and pushing features to get closer to parity with the official Win/Mac client.

But hey there’s plenty of time. This project sat in my drawer for almost two years, I only accelerated things in the last month, and we’re not even two weeks past the first public release yet. Its very probablle that the “flatpak / Flathub DevOps position” will still be open whenever your timing lines up people wanting to help shape and grow the project is honestly what excites me the most regarding this app… right after bit-perfect playback, of course.

Again thank for sharing that insightful findings!

[tbelway]

The whole point of flatpak is to remove system from the equation. I'd be interested to see how you had it configured with your DAC and what interface your DAC uses.

I've tested this on bazzite, fedora 43, and... I can't remember the ublue dev one, something fin. It worked across the board.

We should find time to test it on your end together.

[am4c130d]

I'm running flatpak on OpenSUSE Kalpa with good results. I get bitperfect playback using pipewire, DAC Passthrough to USB DACs. Pipewire does need configuration to switch sample rate automatically. I switched my DAC to Pro mode in KDE PA Control - which allegedly bybasses volume control etc.

I couldn't get ALSA Direct to work.

This app is the best news this year - it addresses two of my three asks of Qobuz - native Linux client, local library support and only headless Qobuz Connect is missing - I can live without that on my laptop.

[vicrodh]

I'm running flatpak on OpenSUSE Kalpa with good results. I get bitperfect playback using pipewire, DAC Passthrough to USB DACs. Pipewire does need configuration to switch sample rate automatically. I switched my DAC to Pro mode in KDE PA Control - which allegedly bybasses volume control etc.

I couldn't get ALSA Direct to work.

This app is the best news this year - it addresses two of my three asks of Qobuz - native Linux client, local library support and only headless Qobuz Connect is missing - I can live without that on my laptop.
@am4c130d It wont be included soon, since a lot of things and bugs are priority in the backlog, but yes, it is in the roadmap ;) thanks to https://github.com/nickblt/qonductor at least first POC worked,

[vicrodh]

In the end, it turns out that Flatpak works best, better than Snap and AppImage, so this survey no longer makes sense.
Thank you for your comments!