It is not a problem to grant the pulseaudio snap the slot access for audio-playback and audio-record (and continue with pulseaudio) but we’ll need to decide how clients should connect to the snap. audio-playback is easy: auto-connect, but audio-record exists solely for the purpose of pulseaudio (or another audio server) to mediate recording by querying snapd to ask if the connecting process is unconfined, classic or has the pulseaudio/audio-record interface connected (ala Ubuntu’s mediation patches). Therefore, to make audio-record meaningful, you need the mediation patches.
You’ll find that once you add these patches, pulseaudio will reach out to the snapd socket and your snap will need to plugs snapd-control (like the recent Request: CUPS Snap ("cups") auto connection to avahi-control, raw-usb, cups-control, and system-files interfaces request), but per @pedronis, the security and the desktop teams, we won’t grant you this access. What is needed is for snapd to grow a new interface so a snap can plugs it and snapd control can mediate the access to its APIs. This is planned and something @kenvandine was going to assign to the desktop team, but I suggest you reach out to him to decide how to proceed (ie, I don’t know their plans or progress; you may be able to help). Without the mediation patches and this change to snapd to allow you to query it, -1 for slotting audio-playback and audio-record (since access to the pulse socket, which audio-playback would grant, would grant recording and it would be way better to have all these things in order instead of granting slot access ahead of it). Once it’s implemented (even just in edge), I’ll be +1.
+1 for to auto-connect alsa and hardware-observe (pulseaudio obviously needs them).
+1 for auto-connecting pulseaudio to bluez as well.
@reviewers - can others please vote on alsa, hardware-observe and bluez?