Hello! I’ve made this ultra simple bash script to switch between audio output cards (planning on adding switching between modes of the same card and inputs) but it doesn’t work without pulseaudio connection (duh). I would like to request an automatic connection to that 
Can you do what you want with the audio-playback interface? The pulseaudio interface was deprecated in favour of audio-playback and audio-record:
I’m honestly not sure if I can. I’m using pulseaudio interface to enable control over host system’s pulseaudio with pactl contained within the snap. If audio-playback and audio-record only do what it says on the tin, I don’t suppose I can.
Also, since my script is entirely pulse-audio specific, I don’t really plan on supporting other sound servers in the short-term.
Both interfaces give access to $XDG_RUNTIME_DIR/pulse/native as pulseaudio does.
At present the only thing audio-playback doesn’t give you is the ability to open a recording stream, with that restriction implemented on the Pulse Audio side (at least on Ubuntu). If you could reconfigure PA via the pulseaudio interface, then it is likely possible via audio-playback too.
With that said: the obvious question is whether this is desirable: I’m not sure whether a snap should expect to be able to reconfigure PA via any of pulseaudio, audio-playback, or audio-record. Blocking such access would probably require expanding the hooks patch set further though. @jdstrand: do you have any thoughts on this?
Ok, so I’ve tried the audio-playback and audio-record interfaces, but I get pa_context_connect() failed: Connection refused error message, thus needing to switch back to the pulseaudio interface. Is there going to be a new interface giving control over pulseaudio sink switching? There are a few snaps that do that, for example pulsemixer.
Oh, actually it seems it works with the audio-playback interface and the pa_context_connect() was caused by another issue. Thanks.
I do not think this is desirable for audio-playback or audio-record. It probably makes the most sense for pulseaudio daemon to be modified to not allow this when the snap has audio-playback/audio-record connected but to allow it when the pulseaudio interface is connected (and then adjust the pulseaudio documentation to no longer say it is deprecated, mention pactl, etc). I think this is inline with the intent of the interfaces: audio-playback/audio-record are ‘generic’ for snaps that are using toolkits/etc that happen to use pulseaudio under the hood (and might move to pipewire/whatever down the line). The pulseaudio interface can still exist for people who really care about pulseaudio itself and want pactl/etc.
@tylnesh - please keep an eye on this thread. We might suggest you to move to plugging ‘pulseaudio’ depending on the outcome.
it sounds a reasonable plan to me, the other option would be to use a new name pulseaudio-control but if it still encompasses playback/record as well that doesn’t make a lot of sense.
I believe we would have it still encompass playback/record since our typical pattern is that ‘control’ encompasses the lesser privileged ‘observe’ interfaces. This is a bit different, but it seems overly fine-grained to split it out. I’m open to it if people feel very strongly about it.
Yes, I’ll keep an eye on this thread. I do realise I’m a newbie around here, but I’d like to say, that it would really be more intuitive to limit audio-playback and audio-record to only playback and recording and either keep pulseaudio as a more complex interface or to create something like audio-control that would enable this kind of features. I’m very happy that the development of snapcraft and snaps is so dynamic, that even such small script can spark a discussion about interfaces.
I answered maybe a bit too hastily. We are still moving away some snaps from using pulseaudio to audio-*? so wouldn’t plainly reusing pulseaudio confuse the transition? or is the transition done?
@pedronis - the transition is done. Everything is grandfathered and all new snaps use audio-* (with snapcraft parts/extensions/etc, docs, electron builder, etc all updated) and this has been true for a number of months. We will need to adjust the docs to say that pulseaudio isn’t needed for playback/record and instead should only be used for controlling it, but this is easy enough. I can work with @degville on this.
1 Like
Yeah, this is the idea and will be a nice improvement.
if you do this, can you take
into account too ?
Is there any particular reason why a confined app would want to use pacmd? If the app is trying to script something, it would be better off using the Pulse Audio API directly or an equivalent pactl invocation.
Well, in the case of (the fully proprietary) zoom i cant even tell if it ever runs pacmd beyond what the invoked qtdiag does at app startup, audio works fine beyond the “no pulseaudio daemon running” error (caused by the fact that qtdiag can not read the pid file), it just connects to the socket anyway, yet i’d personally at least like to see the error go away …
but i also think we should have an interface for apps that actually need/want to use pacmd. though i have no idea how we could filter the protocol to actually protect us from the app unloading the security profiles, this would probably be a bigger effort (similar to what it took to get xdg-open->userd integration)…
Just to be clear, pacmd is implemented entirely differently to the other Pulse Audio utilities. Whereas most of them send commands to PA using its native binary protocol to $XDG_RUNTIME_DIR/pulse/native, pacmd is effectively a prettier version of “nc -U $XDG_RUNTIME_DIR/pulse/cli”. It is speaking a text protocol implemented within the server. It is effectively a back door debugging protocol that may not even be available if the module implementing it is unloaded.
There is overlap between what is possible via PA’s native protocol and what is possible over the cli text protocol socket. So it is a legitimate question of whether the application needs to use pacmd, or whether they just picked the first thing that worked.
Using the native protocol is likely to be safer and more reliable, and likely the only route we can realistically secure.