Thanks!, adding the ‘x11’ plug to the yaml file fixed this problem.
I don’t understand though what the ‘x11’ plug has to do with PulseAudio access. Should somehow the ‘pulseaudio’ plug have an implicit dependency on the ‘x11’ plug?. I’m not a PulseAudio developer, just a user of the pulseaudio library.
From an app developer point of view, this is to me perhaps the most important issue with snaps right now. The fact that the ‘interfaces’ concept appears as an internal detail of the snap system that has been exposed a bit “too much” to the app’s developer. I.e. you need to be aware of the interfaces required by your code and by some of your dependencies’ code. Better tooling might be able to help here in the future (e.g. thinking of some form of static or dynamic analysis of interface issues).
Another question that came to mind while snapping Tizonia is what is the point of listing “auto-connected” interfaces in a ‘strict’ snapcraft.yaml file. If they are auto-connected, I believe they will be completely transparent to most users of the app, so you could make perhaps the case of them being “auto-granted” to all ‘strict’ apps anyway?. I’m probably missing something here.
Don’t get me wrong, I love the idea of packaging my app as a snap. By far the nicest vehicle I’ve found of distributing it so far. But interfaces has made it a bit harder than I feel it could have been, so just sharing a bit of feedback here.