Digitally silent recordings: PulseAudio is started even for direct ALSA devices (and two neighbours of that bug)

[Yannick158]

Posting this as a discussion as well as a PR, because it is the kind of thing
you only find by accident, and the symptom gives you nothing to search for.

The symptom

Recordings are digitally silent. Not quiet — silent: WAV files of the
right length and the right size, appearing at the normal rate, amplitude
exactly 0.000000. The service is active, the disk fills up, nothing is
logged, and BirdNET simply reports no detections.

Check it on your own station:

sox $(ls -t ~/BirdSongs/StreamData/*.wav | head -1) -n stat 2>&1 | grep Maximum

Maximum amplitude: 0.000000 is a dead giveaway. Real room noise sits
around 0.001–0.01.

The cause

scripts/birdnet_recording.sh starts PulseAudio unconditionally before
arecord:

if ! pulseaudio --check;then pulseaudio --start;fi

If your REC_CARD is a direct ALSA device — plughw:…, hw:…, dsnoop:…,
or a custom PCM from /etc/asound.conf — PulseAudio opens the card first and
arecord gets a device that is already taken. On a headless install it
cannot work even in principle: with no session bus there is nowhere for
PulseAudio to hand the stream on.

The fix

Start PulseAudio only for devices that actually go through it:

case "${REC_CARD}" in
  ''|default|pulse|pulse:*) if ! pulseaudio --check;then pulseaudio --start;fi ;;
esac

The empty case is deliberate: with no REC_CARD, arecord runs without -D
and uses the ALSA default, which on a desktop install is PulseAudio. Those
setups keep working exactly as before. Only the case that is currently broken
changes.

I have this open as #653 if a maintainer wants to take it. Until then the
edit above is three lines in one file, and it survives until the next update
overwrites it.

Worth knowing: the AvianVisitors fork already does this

Twarner491/AvianVisitors
arrived at the same guard independently and ships it today:

case "${REC_CARD:-}" in
  ''|default|pulse) ensure_pulseaudio ;;
esac

Two people hitting the same wall and writing the same four lines is
reasonable evidence that it belongs upstream.

Two neighbours of this bug

While chasing it I hit two more things that produce "no detections" with no
error. Both are configuration rather than code:

Card numbers move across reboots. A USB microphone that was card 3 can
come back as card 1, and REC_CARD="plughw:3,0" then points at nothing.
The unit fails on every start and sits in activating, so it never shows as
failed — easy to miss for weeks. Use the stable name instead:

arecord -L | grep '^plughw:CARD='
REC_CARD="plughw:CARD=Device,DEV=0"

The live stream and the analysis cannot both hold the microphone, because
both open $REC_CARD and most USB capture devices allow one client. The
usual advice is to disable livestream.service. You do not have to — ALSA's
dsnoop splits one capture stream between several readers. The important
detail, which cost me an evening: put a plug in front of the dsnoop PCM and
point REC_CARD at that, not at the dsnoop device directly. Without the
plug wrapper, a client asking for a rate or format the slave does not
provide fails to open — which is exactly what happens to ffmpeg while
arecord keeps working fine.

pcm.dsnooper {
    type dsnoop
    ipc_key 2048
    slave {
        pcm "hw:CARD=Device,DEV=0"
        channels 1
        rate 48000
        format S16_LE
        period_size 1024
        buffer_size 8192
    }
}

pcm.birdmic {
    type plug
    slave.pcm "dsnooper"
}

Then REC_CARD="birdmic", and both services run off the same microphone.
Two readers at once proves it:

arecord -D birdmic -d 3 -f S16_LE -r 48000 /tmp/a.wav &
arecord -D birdmic -d 3 -f S16_LE -r 48000 /tmp/b.wav

All three are written up as a docs page in a PR on the AvianVisitors side;
happy to open the same here if that is wanted.

Running on a Pi 4, Bookworm, headless, USB mic, since August — about 10 000
detections through a dsnoop PCM with both services live.