Permission error when running as systemd service about birdnet-go

[tphakala]

All paths in birdnet-go config are relative by default, you need to set working directory in systemd config unless you configure absolute paths in config (like path: /opt/birdnet-go/logs/webui.log).

This is my /etc/systemd/system/birdnet-go.service

[Unit]
Description=BirdNET-Go Analyzer Service

[Service]
ExecStart=/home/thakala/birdnet-go realtime -d
Restart=on-failure
User=thakala
Group=thakala
WorkingDirectory=/home/thakala

[Install]
WantedBy=multi-user.target

To fix ALSA permission issue you need to add birdnet user as member of audio group

sudo usermod -a -G audio birdnet

[farski]

WorkingDirectory worked, thanks! Unfortunately, even when birdnet is a member of the audio group…

birdnet@birdnet:~ $ groups
birdnet adm dialout cdrom sudo audio video plugdev games users input render netdev gpio i2c spi

…I'm getting the same ALSA errors

[tphakala]

Have you tried rebooting Linux after adding birdnet user to audio group? Does alsamixer work with birdnet user?

[farski]

I have rebooted, and alsamixer does work for the birdnet user (or at least it launches and I can change the volume

[tphakala]

I did a lot testing today and I now know what is wrong.

"ALSA lib pcm_dsnoop.c:566:(snd_pcm_dsnoop_open) unable to open slave" error is caused by BirdNET-Go trying to use ALSA device which is already open, in your case it is most likely caused by PulseAudio which BirdNET-Pi is using as audio backend.

This can be solved by configuring BirdNET-Pi to use dsnoop as audio card, this is capture device type which can be shared by multiple applications

There is also bunch of ALSA audio plugins in BirdNET-Pi os which need to be made unavailable for ALSA, non-destructive way to disable them is to rename /etc/alsa/conf.d for example /etc/alsa/conf.d.off.

Once you reboot BirdNET-Pi should record on dsnoop device and BirdNET-Go should also tap to that same device.

This works only with locally installed birdnet-go, recently released Docker image is unable to use shared dsnoop device.

[farski]

@tphakala Thanks for all that testing! The computer where I'm currently running BirdNET-Go actually does not have BirdNET-Pi on it anywhere. This was a fresh OS with only BirdNET-Go installed.

I do see pulseaudio running in top, though. In the other thread I know you said you disable Pulse Audio for BirdNET-Go, so perhaps it's a similar issue? Though when I have tried running BirdNET-Go through systemd, I always stop any other running instances first, so I wouldn't expect them to be competing. But I don't think I've ever tried running it via systemd after a restart without having run it manually at all, so maybe something is hanging around. I can test that.

But also maybe once I'm on a version that doesn't use Pulse Audio at all it won't matter?

[tphakala]

I disabled Pulse Audio because it is causing inconsistent behavior due to how Pulse Audio works by default. When you login to Linux shell, by SSH or by any other means, this will typically also spawn a Pulse Audio server, once you log out Pulse Audio server stops.

Miniaudio library I am using in BirdNET-Go connects to Pulse Audio server if it is available, if it is not it falls back to ALSA. In your case Pulse Audio backed audio works, but ALSA does not (hence errors with systemd launched process).

Could you try to add following config into /home/birdnet/.asoundrc (or to profile you are running BirdNET-Go as)

pcm.capture {
    type dsnoop
    ipc_key 5678
    slave {
        pcm "hw:0,0"
        channels 2
        rate 48000
        format S16_LE
    }
}

pcm.!default {
    type hw
    capture.pcm {
        type plug
        slave.pcm "capture"
    }
}

This will configure ALSA to provide audio capture device as dsnoop type device which can be shared between processes.

[tphakala]

Is your system a full desktop install or is it a minimal install?

[farski]

Is your system a full desktop install or is it a minimal install?

I believe it was a vanilla Raspberry Pi OS Lite 64 bit install from a few weeks ago

[jetpacktuxedo]

@farski idk if you are still having this issue, but I was seeing the same thing and fixed it by adding

ExecStartPre=/usr/bin/pulseaudio --start

to my systemd script. I think the pulseaudio server doesn't get started for systemd sessions, and this triggers it to start up before it kicks off the normal startup process.

There might be a better way to do this because linux audio is far from my strong suit, but it seems to be working for me 😅