Request for audio related snap declarations for ubuntu-desktop-session snap

store-requests
#1

We want to add support for audio to our graphical Ubuntu Core variant, which in turn will require some snap declaration changes. Namely:

  1. 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.
  2. 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.

#2

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…

#3

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.

#4

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.

#5

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.

#6

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…

#7

Any votes on this request?

#8

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.

2 Likes
#9

I’ll +1 this as well.

1 Like
#10

Is this enough to have the changes applied to the snap declaration?

1 Like
#11

+2 votes for, 0 against, granting use of the requested audio related snap declarations. This is now live.

1 Like
#12

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.

#13

@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?

#14

Just to close the loop on this so I don’t come back and look at it in the future: this has been rectified.

1 Like