Manual permission approval request for "SongRec"


I have recently wrote a graphical, GTK+-based Shazam client for Linux, SongRec:

I have began distributing it through a few channels, it was validated on Flathub:

I have uploaded a Snap package to Snapcraft, which isn’t public yet due to the requirement of approval for the DBus service interface: hxxps://

The source of the concerned Snap package is publicly available here: hxxps://

I am requesting here:

  • Auto-connection for the “audio-record” interface plug: this is required to achieve the basic functionality of the application (song recognition from the microphone). Also, there isn’t any possible privacy risk/ because the upstream servers that perform recognition don’t receive actual audio (they just receive an array of some (amplitude, frequency, time) tuples for the strongest peaks of a sound excerpt, which can lead to recognize a known song but isn’t hearable sound).
  • Auto-connection for the “dbus-svc” slot for the “com.github.marinm.songrec” DBus interface: this is required for the app to launch because this is a standard GTK+ 3 app which binds to a DBus service when launched, in order to handle multi-instance behavior, etc. If this interface slot is not set, then the app fails with an AppArmor error message at startup.


Hi @Marin, welcome to the forum!

On Fri 13 Nov. 2020, I granted #2 the use of the well-known DBus name, com.github.marinm.songrec, to this snap.

Regarding audio-record auto-connection, I am +1 since this is a core functionality for songrec snap. Can other @reviewers please vote?

+1 from me for auto-connection of audio-record. Since one of the key features is “Recognize audio from the microphone”, it should come as no surprise to users that SongRec can use their microphone.

+1 from me for auto-connection of audio-record, as well, as it’s core part of the SongRec functionality.

+3 votes for, 0 votes against, granting auto-connect of audio-record for songrec. This is now live.

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)


It seems that granting the audio-record connection to the Snap will not actually allow it to record sound.

As it is visible on the screenshot below, no audio device will be detected on Ubuntu 18.04 or 20.04:

It seems that it is because the cpal library, which is used by the underlying rodio library which I use to process and record audio, only supports ALSA as a backend for recording audio, as it is indicated here:

This is how it works in Ubuntu 18.04, and probably what you’d like to setup to test:
cpal -> libasound2 (ALSA) -> libasound_module_pcm_pulse (ALSA plugin) -> libpulse (PulseAudio).

I have tried to add an alsa connection to the Snap (revision #3). However, when connecting the concerned alsa interface onto the span (with sudo snap connect songrec:alsa :alsa), the application does not start or display and seems to quit without motivation.

Does it mean that classic confinment may be required for this snap to work live and that I should re-submit it as such?


have you considered using the alsa-mixin part in your snapcraft.yaml ?

that should reliably re-map alsa to pulse in/output for your application…


Thanks for the advice. I have uploaded a version #4 of the package with the “alsa-mixin” included and this seems to detect input sound devices when additionally adding the “:alsa” interface connection to the package.

@alexmurray Is it possible to add an additional auto-connect for the “:alsa” interface for the package to work, please? (I guess that this doesn’t require an additional voting procedure?)

1 Like