We want to add support for audio to our graphical Ubuntu Core variant, which in turn will require some snap declaration changes. Namely:
allow D-Bus slots claiming the names org.pulseaudio.Server and org.freedesktop.ReserveDevice1 on the session bus. These are used by the pipewire components we’re running as part of the snap.
we’re adding audio-playback, audio-record, and pulseaudio slots. These should have similar connection policies to the equivalent implicit slots on classic systems. I realise that the pulseaudio interface is deprecated in favour of the first two, but without it old snaps still using it as a plug won’t have anything to connect to.
I think the snap declaration changes I want would look something like this:
slots:
dbus:
allow-connection:
-
slot-attributes:
name: org.pulseaudio.Server
-
slot-attributes:
name: org.freedesktop.ReserveDevice1
# plus all the other cases already in the declaration...
deny-auto-connection: true
audio-playback:
allow-installation: true
allow-connection:
on-classic: false
allow-auto-connection:
on-classic: false
audio-record:
allow-installation: true
allow-connection:
on-classic: false
allow-auto-connection: false
pulseaudio:
allow-installation: true
allow-connection:
on-classic: false
allow-auto-connection: false
Note that allow-auto-connection for audio-record and pulseaudio should be more restrictive than audio-playback, as it is in the base declaration. I think it’d be useful to follow the pattern we used for the desktop/wayland/x11 slots, and only make it a connection candidate on Ubuntu Core systems.
Would be cool if snapd could eventually grow something like “slot aliases” for this so audio-playback could simply provide pulseaudio… we can not carry deprecated interfaces forever…
The problem there is that pulseaudio is not equivalent to audio-playback, since it also allows recording audio. It’s also not equivalent to audio-record, since that’s currently just a marker interface that does nothing without also having an audio-playback plug.
Indeed, there would be limitations… but then, pulseaudio has been deprecated years ago and snaps should really switch eventually and use assumes: … having audio playback only and a warning that the snap should be updated by its maintainer when it actually uses record as well seems like a doable compromise … technically the audio-* interfaces together provide exactly what pulseaudio did.
I ran my script to grab the snap.yaml files for all public snaps, and was able to find 383 snaps with a pulseaudio plug but no audio-playback plug. I haven’t checked that all these snaps have a snap declaration that would let the plug connect, but the first few I checked had it.
I agree that we should aim to get rid of the interface eventually, but I’m not sure whether we’d want to make that decision for this prototype before we do it for snapd proper.
No, definitely not, this should indeed happen properly coordinated on a snapd level, this is a bigger fish to fry, sorry for abusing the request as a dumpster to plant my pass-by ideas, there needs to be proper planning and architect involvement…
Apologies for the delay in looking at this request - +1 from me on all of these requests since ubuntu-desktop-session is bundling pulseaudio etc and wanting to act as the sound server / service.
Thank you for this. Looking at the new assertion, I see this:
slots:
...
pulseaudio:
allow-installation: true
With no allow-connection or allow-auto-connection rules, will this end up with the right semantics? We want the pulseaudio slot to have the same semantics as audio-record: allow connection, but deny auto-connection to snaps without a relevant plug declaration to enable it.
@dclane: It also looks like the updated assertion removed the declaration for the desktop slot. I had not requested that change, and it breaks our images. Could we have that added back?
