Manual permission approval request for "SongRec"

store-requests
1

Hello,

I have recently wrote a graphical, GTK+-based Shazam client for Linux, SongRec: https://github.com/marin-m/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://dashboard.snapcraft.io/snaps/songrec/revisions/2/

The source of the concerned Snap package is publicly available here: hxxps://github.com/marin-m/SongRec/blob/master/packaging/snap/snapcraft.yaml

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.

Regards,

2

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?

3

+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.

4

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

5

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

7

Hello,

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:

screenshot

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: https://github.com/RustAudio/cpal/issues/259

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?

Regards,

8

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…

9

Hello,

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
10

@lucyllewy above ogra suggested the use of snapcraft-alsa which might help for this snap’s use-case. But the docs for snapcraft-alsa are not clear - on https://snapcraft-alsa.readthedocs.io/en/latest/index.html it says

This part will install ALSA and a snap configuration that will redirect audio through pulseaudio without requiring the alsa plug to be connected manually or by store assertion.

But then the instructions at https://snapcraft-alsa.readthedocs.io/en/latest/snapcraft_usage.html show plugging alsa - so I am confused - does the snap need to plug alsa still with this solution?

@Marin in your case, looking at your updated snapcraft.yaml I notice you have not added the alsa-launch command-chain part from the docs - perhaps that will help?

11

The part will attempt to use ALSA if it can, i.e. if the user has connected the alsa interface, but will allow the user to fall-back to pulseaudio if they prefer the safer execution confinement that the audio-playback interface has over alsa. On first run the user is prompted with a popup to choose to connect alsa or try pulseadio once, or always use pulseaudio and never prompt again.

12

Thanks for the prompt response @lucyllewy - @Marin so from this description there should not be a need to auto-connect alsa from what I understand - you just need to ensure you use the alsa-mixin part properly via the command-chain so it gets a chance to prompt the user. As such, -1 from me for auto-connect of alsa for songrec.

1 Like
13

As an aside, I see you’re using the gnome-3-34-1804 content snap, but are doing so via the unusual route of the desktop-helpers code. You can probably improve things by removing the desktop-gnome-platform part and change your apps block to the following, which also fixes the alsa/pulseaudio invokation:

apps:
  songrec:
    command: songrec
    command-chain: [bin/alsa-launch]
    extensions: [gnome-3-34]
    desktop: usr/share/applications/com.github.marinm.songrec.desktop
    plugs: 
      - home
      - network
      - desktop
      - desktop-legacy
      - wayland
      - unity7
      - gsettings
      - alsa
      - audio-record
      - audio-playback
    slots: [dbus-svc]
14

Hello,

Thank you for your further insight.

With just the “:alsa” interface connected, or with both the “:alsa” interface and the “snapcraft-alsa” mixin fully integrated including the launch command, the application crashes when trying to list devices. Here is what I could obtain when re-enabling standard error output at the moment of the crash (I previously disabled it because libasound was polluting the terminal with plugins-related warnings in normal operation conditions):

ALSA lib control.c:1379:(snd_ctl_open_noupdate) Invalid CTL hw:0
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: BackendSpecific { err: BackendSpecificError { description: "ALSA function \'snd_device_name_hint\' failed with error \'ENOENT: No such file or directory\'" } }', src/gui/main_window.rs:144:44
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

It seems that snd_device_name_hint in libasound is hit by a filesystem access restriction.

When the “:alsa” interface is not connected but the mixin is fully integrated, including the launch command, the application displays no input devices, as depicted in the screenshot above.

It seems the only case when I could obtain actual audio recording devices to be displayed but no crash, is at a moment where I added the mixin, the “:alsa” interface but not the extra snap/command-chain/alsa-launch launch command.

What should I conclude?

As an aside, I see you’re using the gnome-3-34-1804 content snap, but are doing so via the unusual route of the desktop-helpers code. You can probably improve things by removing the desktop-gnome-platform part and change your apps block to the following, which also fixes the alsa/pulseaudio invokation:

It seemed to me that the GNOME 3 extension was compatible with Snaps built over the core18 environment, not core20, at the contrary of the GNOME 3 desktop helper, and that I could not have it work with a core20 setup (nor could I switch my package to core18 for other unrelated reasons). Is this meant to have changed recently?

This is also what the documentation says: https://snapcraft.io/docs/gnome-3-34-extension

This extension currently only works with the core18 base snap (see Base snaps for details).

Regards,

15

Sorry, I missed that you’re targetting core20 you can disregard that thought then :slight_smile: