Thanks for this!
At the sprint, it was decided between @niemeyer, myself, @zyga, @willcooke and @kenvandine that we would indeed introduce the ‘audio-record’ and ‘audio-playback’ interfaces, and keep ‘pulseaudio’. Today, audio-record/audio-playback would contain policy for pulseaudio recording and playback, respectively (though see below), and we would add pipewire or anything else with mediated playback and record to these interfaces as appropriate going forward. The ‘pulseaudio’ interface would allow both playback and record for pulseaudio specifically, and we would deprecate its use going forward (ie, adjust templates to use ‘audio-playback’ instead of ‘pulseaudio’, etc). The description of your implemention is completely inline with these decisions where pulseaudio is doing all the mediation (so the security policy ends up being the same in all 3 interfaces).
As for ALSA, we already have an alsa interface and people are free to use it, but it of course has direct access to the audio devices and therefore requires manual connection. Using a mediated sound service (in this case, pulseaudio, but in the future pipewire or whatever) is key to security, in this case, audio-playback is auto-connected and audio-record is manually connected. I don’t think we should encourage people to use ALSA instead of pulseaudio (or pipewire) since it is uneeded for the common case of playbackc and simple recording. Advanced audio applications (eg, jackd, etc) can of course target ALSA.
I’ve not looked at your pulseaudio code, but it sounds like the next step is a PR to snapd that defines pulseaudio plugs policy in pulseaudio_common.go, then you modify pulseaudio.go to import that, and create simple audio_playback.go and audio_record.go that do the same. Please ping me if you need help with this or when you have a PR to review.