fix: remove PipeWire socket to restore audio on many existing Linux systems

[fermulator]

Fixes #383

Problem

Commit 9b26fc9 (PR #380, May 2026) added --filesystem=xdg-run/pipewire-0:ro to the manifest with the rationale "Spotify uses pipewire by default now."

This causes silent audio failure on systems where PipeWire is installed but not serving audio (e.g. Ubuntu 22.04). Spotify's CEF (Chromium 146) detects the PipeWire socket in the sandbox, selects PipeWire as its audio backend, and commits — there is no fallback to PulseAudio. On systems where PipeWire is not the audio server, the result is no audio with no error message.

Why removing the line is the correct fix

Spotify does not need direct PipeWire socket access. Audio playback works through --socket=pulseaudio, which is already in the manifest:

• On PipeWire systems with pipewire-pulse (Fedora, Bazzite, Arch with pipewire-audio, most modern desktops): pipewire-pulse intercepts PulseAudio connections and routes them through PipeWire natively. Full PipeWire audio, zero configuration.
• On PulseAudio systems (Ubuntu 22.04, older distros): connects to PulseAudio directly.

This works because --socket=pulseaudio connects to whatever is listening on the PulseAudio socket — whether that's actual PulseAudio or PipeWire's PulseAudio compatibility layer. No detection, no fallback logic needed.

Note: pipewire-pulse is not a dependency of pipewire on any major distro — it's a separate optional package. Systems like Ubuntu 22.04 ship PipeWire for screen sharing (xdg-desktop-portal) but use PulseAudio for audio, with no pipewire-pulse installed. Exposing the PipeWire socket on these systems is what causes CEF to select the wrong audio backend.

How other Flatpak apps handle this

App	--socket=pulseaudio	PipeWire socket	Notes
Firefox	Yes	No	PulseAudio only — PipeWire handled via pipewire-pulse
Slack	Yes	No	Same approach
Signal	Yes	No	Same approach
Teams	Yes	No	Same approach
Discord	Yes	xdg-run/pipewire-0 (r/w)	Added by Discord engineer for Steam Deck screen sharing (DiscordCanary#682), not for audio
Spotify	Yes	xdg-run/pipewire-0:ro	No screen sharing — socket serves no purpose

Discord is the only other app that exposes the PipeWire socket, and it does so for a specific non-audio feature (screen capture in Steam Deck game mode) requested by a Discord engineer. Spotify has no equivalent use case.

Why not just drop :ro?

Initial testing on Bazzite 44 (PipeWire 1.6.6) showed no audio with :ro, and audio worked after overriding to read-write. However, after reverting to the stock :ro manifest and rebooting, audio worked again — the failure was not reproducible.

This is consistent with how Unix sockets work: connect(), send(), and recv() bypass the filesystem mount's read-only flag. The :ro restricts file creation/deletion in the mount path, not socket communication. The initial failure was likely a transient PipeWire session issue, not caused by :ro itself.

The real problem is exposing the socket at all, which causes CEF to select PipeWire as the audio backend on systems where PipeWire is present but not serving audio (e.g. Ubuntu 22.04). Dropping :ro does not fix that.

Tradeoff: compatibility over direct PipeWire

This change means CEF will use the PulseAudio API on all systems, including modern PipeWire desktops. The audio path on those systems becomes:

Spotify → PulseAudio API → pipewire-pulse → PipeWire → hardware

Instead of the direct path available when the PipeWire socket is exposed:

Spotify → PipeWire API → PipeWire → hardware

For a music player streaming 44.1kHz audio, the practical difference is negligible — pipewire-pulse is a thin translation layer, not a full server. Latency, sample rates, and format negotiation all pass through fine.

We favour compatibility here: silent audio failure with no error message on Ubuntu 22.04 LTS (supported until 2027) and similar systems is worse than an imperceptible extra hop on modern desktops.

When Flatpak adds --socket=pipewire support, the manifest should declare both --socket=pulseaudio and --socket=pipewire — that would give CEF proper access on modern systems while still falling back gracefully. As of Flatpak 1.17.7, pipewire is not a valid socket type.

Workaround (for users on current version)

mkdir -p ~/.var/app/com.spotify.Client/config
echo "--audio-api=pulseaudio" > ~/.var/app/com.spotify.Client/config/spotify-flags.conf

This forces CEF to skip PipeWire and use PulseAudio directly. Remove after this fix is released.

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[fermulator]

@Erick555 - git blame shows you originally added the pipewire line:

--filesystem=xdg-run/pipewire-0:ro

Please take a look here, and at #383 for context

[flathubbot]

❌ Test build failed.

Help

• bot, build - Restart the test build
• bot, ping admins - Contact Flathub admins

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[fermulator]

The initial attempt for socket completely failed (and is not valid) -- tested locally, and this confirms per build failure earlier https://github.com/flathub-infra/vorarbeiter/actions/runs/27923950773

--
NEW changes work!

local test results

flatpak override --user --filesystem=xdg-run/pipewire-0 com.spotify.Client
# remove previous pulseaudio workaround
rm ~/.var/app/com.spotify.Client/config/spotify-flags.conf
killall spotify; sleep 2; flatpak run com.spotify.Client &
$ pactl list short sink-inputs
747     66      746     PipeWire        float32le 2ch 44100Hz
$ pactl list short clients | grep spotify
746     PipeWire        spotify

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/296269/com.spotify.Client.flatpakref

Built for x86_64 architecture.

[fermulator]

$ flatpak override --user --reset com.spotify.Client
$ flatpak install --user https://dl.flathub.org/build-repo/296269/com.spotify.Client.flatpakref
The application com.spotify.Client depends on runtimes from:
  https://dl.flathub.org/repo/
Configure this as new remote 'flathub' [Y/n]: 

com.spotify.Client permissions:
    ipc      network      fallback-x11      pulseaudio     wayland     dri     file access [1]     dbus access [2]     bus ownership [3]     tags [4]

    [1] xdg-music:ro, xdg-pictures:ro, xdg-run/pipewire-0
    [2] org.freedesktop.ScreenSaver, org.gnome.SettingsDaemon.MediaKeys, org.kde.StatusNotifierWatcher
    [3] org.mpris.MediaPlayer2.spotify
    [4] proprietary


        ID                          Branch          Op          Remote                 Download
 1. [✓] com.spotify.Client          test            i           client-origin          186.9 MB / 187.0 MB

Installation complete.

spotify audio worked off the test branch build ✔️

[fermulator]

(!) WARNING: on further consideration, i don't think this actually fixes the PROBLEM introduced by #380

Next line of thinking is that the introduction of pipewire has resulted in incorrect latch to non-functioning audio subsystem on legacy systems, and they aren't falling back to pulseaudio .

[flathubbot]

🚧 Test build enqueued.

[flathubbot]

🚧 Started test build.

[flathubbot]

✅ Test build succeeded. To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/296272/com.spotify.Client.flatpakref

Built for x86_64 architecture.

[Erick555]

Please take a look here, and at #383 for context

The context that is completely missing from this PR is spotify 1.2.86.502.g8cd7fb22 required pipewire socket to play audio in default config on all systems. As for version 1.2.92.147.g5b8f9367 it seems they may changed it to make it work without pipewire socket although there are mixed user reports about that. This is all context someone need to understand this issue, those walls of text of LLM output have no relevance but add extreme noise.

(!) WARNING: on further consideration, i don't think this actually fixes the PROBLEM introduced by #380

So removing pipewire socket still doesn't make audio work on legacy systems in your testing? Or did you comment about different state of this PR? As I see it went back and forth on removing and re-adding pipewire socket.

I would need confirmation from you and users who reported no audio on stock config that installing latest test build fixes it for them without using workaround in ~/.var/app/com.spotify.Client/config/spotify-flags.conf.

[fermulator]

Please take a look here, and at #383 for context

The context that is completely missing from this PR is spotify 1.2.86.502.g8cd7fb22 required pipewire socket to play audio in default config on all systems. As for version 1.2.92.147.g5b8f9367 it seems they may changed it to make it work without pipewire socket although there are mixed user reports about that. This is all context someone need to understand this issue, those walls of text of LLM output have no relevance but add extreme noise.

(!) WARNING: on further consideration, i don't think this actually fixes the PROBLEM introduced by #380

So removing pipewire socket still doesn't make audio work on legacy systems in your testing? Or did you comment about different state of this PR? As I see it went back and forth on removing and re-adding pipewire socket.

I would need confirmation from you and users who reported no audio on stock config that installing latest test build fixes it for them without using workaround in ~/.var/app/com.spotify.Client/config/spotify-flags.conf.

@Erick555

yes that comment was from the initial state of using read-write socket - it DID fix problem for my Bazzite system (but when i reverted it it started working suddenly which was odd)

I CAN confirm that spotify works again without the pipewire entry at all on the manifest (and without any workarounds) using this test build with this change

under what circumstances did you originally need to add pipewire explicitly? (this doesn’t make sense to me - it’s still defacto standard to support pulse audio … shouldn’t be any system that doesn’t ship with support for it)

[fermulator]

latest state of this PR is proposing to revert explicit pipewire in manifest because some legacy systems hook into it but they aren’t hooked up for audio

go back to pulse audio because there are hundreds of users reporting broken spotify app after the change in May

[Erick555]

under what circumstances did you originally need to add pipewire explicitly? (this doesn’t make sense to me - it’s still defacto standard to support pulse audio … shouldn’t be any system that doesn’t ship with support for it)

Spotify defaulted to pipewire output and didn't use pulseaudio fallback without passing --audio-api=pulseaudio explicitly. This wasn't first weird behavior or regression in recent months.

[fermulator]

under what circumstances did you originally need to add pipewire explicitly? (this doesn’t make sense to me - it’s still defacto standard to support pulse audio … shouldn’t be any system that doesn’t ship with support for it)

Spotify defaulted to pipewire output and didn't use pulseaudio fallback without passing --audio-api=pulseaudio explicitly. This wasn't first weird behavior or regression in recent months.

OK so the app itself only output to pipewire? (and as such the container needed it for pass through?)

Maybe this was an interim state? It’s working now without the pipewire line so i think we should go back to pulseaudio like every other mainstream upstream pkg

[Erick555]

Yes, app only outputted to pipewire unless pulseaudio flag was added in config.

If you install spotify from official .deb archive then it would have access to all sockets on system including pipewire so flatpak should currently give exact same experience as non-flatpak.

[fermulator]

confirmed bug and working on older Mint system, no audio without redirect workaround
(on that system had to downgrade and hold apt to 1.2.63.394.g126b0d89, because their latest ships with a newer GLIBC dependency which Mint cannot satisfy)