Upcoming pulseaudio interface deprecation

When the pulseaudio interface was written, it was known to be a transitional interface since it gives full access to only pulseaudio (and no other sound servers) without a design for mediating audio recording.

As of 2.41, snapd adds the audio-playback (auto-connected) and audio-record (manually connected) interfaces. These interfaces currently support using the host’s PulseAudio sound server and will be extended to support other sound servers as required (eg, pipewire). In this manner, snaps are future-proofed and need only plugs audio-playback to have access to the configured sound servers on the system (as supported by snapd) as opposed to having to specify multiple interfaces for different sound servers (ie, plugs: [ audio-playback ] vs plugs: [ pulseaudio, pipewire, foo, bar ]).

Furthermore, for host systems that support the snapd-integration patch for pulseaudio, pulseaudio will mediate recording by verifying that the audio-record interface is connected by the client snap.

Next steps

Though the pulseaudio interface is being deprecated, it will not be removed from snapd and you are free to continue plugging pulseaudio as always. In the coming weeks, pulseaudio will change from being auto-connected to being manually connected. During this transition, all existing snaps that currently plugs: [ pulseaudio ] will be grandfathered into auto-connection.

As of today, the forum documentation has been updated to suggest using these new interfaces instead of pulseaudio, the snapcraft-desktop-helpers have been adjusted to plugs: [ audio-playback, pulseaudio ], bugs have been filed in other projects that provide templates (eg, electron), snapd 2.41 is finding its way out to various distributions and the grandfathering of existing snaps has begun.

Your snaps

If your snap currently plugs: [ pulseaudio ], you may want to opt into future-proofing and adjust it to use plugs: [ audio-playback, pulseaudio ] (adding audio-record as desired). Again, this is not required for existing snaps since they will be grandfathered into auto-connection.

Your templates

If you use the snapcraft-desktop-helpers, you may want to verify your new snaps are using the latest version that pull in audio-playback.

If you use another snap template system that still only plugs pulseaudio, feel free fix it to additionally plugs audio-playback and/or report this upstream and report back here.

Happy snapcrafting!


That seems like an elegant way to handle things. Thanks @jdstrand!


FYI, the grandfathering is completed for all snaps with a populated stable channel. I’ve now issued https://github.com/snapcore/snapd/pull/7631 to make pulseaudio manually connect (milestoned for 2.43). @pedronis and I will make sure we’ll do another round of updates when/before 2.43 is released.

@advocacy - besides snapcraft-desktop-helpers and electron-builder, are there any projects that templatize snapcraft.yaml/snap.yaml to add pulseaudio?

It might be useful adding a snapcraft warning so when developers build a snap and only have pulseaudio declaration for new snaps, there will be a cli prompt that warns them of the deprecation and lists the suggested future proofing method.

A similar warning could also be added to launchpad and the build service.

This way we will catch anyone with snaps in non-stable channels, and anyone developing without re-consulting the documentation (existing knowledge).

1 Like

This is now merged into master and will be in 2.43.

I was thinking of updating the review-tools to have a check for ‘if not grandfathered and plugs pulseaudio and not plugs audio-playback: warn to also plugs audio-playback’ (with a mechanism to override). It probably makes sense for snapcraft to guide as well (though note, snapcraft-desktop-helpers was updated already). cc @pedronis and @sergiusens

FYI, snapd 2.43 is now in the stable channel and pulseaudio in 2.43+ is now manually connected. As promised, we’ve issued snap declarations to grandfather in snaps uploaded to the store that plugs pulseaudio.

If we’ve missed an existing snap, we apologize. Please note you can always upload a new revision that plugs ‘audio-playback’ to fix your snap without store intervention, or if you don’t want to create a new revision, feel free to create a new topic in the ‘store-requests’ category and we’ll expedite the request to grandfather any existing snaps.

I assume snapd 2.41 is not yet everywhere snaps are supported? Do we know when it will be appropriate to drop pulseaudio from existing snap recipes?

For classic distros that don’t support reexec, I see that:

  • Parrot OS (they are debs, does it support reexec?) has both 2.37.4 and 2.42.1 in its repo
  • Raspian (they are debs, does it support reexec?) has both 2.37.4 and 2.42.1 in its repo

Looking at solus, it appears that they have deltas from last month so I think they are ok. Everything else I checked (again, that doesn’t reexec; ie, Arch, CentOS 7, Fedora 30, Manjaro, OpenSUSE) all have 2.41 or newer.

@mvo - can you or someone supporting cross-distro comment on Parrot OS, Raspbian and anything else regarding @alan_g’s question?

I can’t say for sure, but by default, “debian like”[1] distros do re-exec unless it is explicitly disabled by the packaging by setting an env variable (the env var setting to disable re-exec is SNAPD_REEXEC=0`).

[1] As defined by ID_LIKE variable in /etc/os-release

would be nice if solus could also be updated:

@mvo - in case it wasn’t clear, can someone working on cross-distro reach out to solus? The version of solus that the person who reported the bug that @ogra mentioned apparently only has snapd 2.39.

Solus users are being hit by quite a few other problems due to the outdated snapd, too. I recently had to adjust a couple of my forward-thinking snaps to account for lack of support for some snapd features in Solus.