Dynamic Normalization is to much for a Pi Zero to handle.

[JasonLG1979]

See:
dtcooper/raspotify#504

Basically the combination of (the new) dynamic normalization and the CPU spike that generally happens when a track is buffering is just above what the Pi Zero can handle and it throws ALSA into a error loop that hangs the CPU at 100% for a while before finally dying.

There's not much that really can be done I don't think, this issue is more for something to link to if others have the same problem.

The solution is to just not enable dynamic normalization on the Pi Zero.

[roderickvd]

A reason to not deprecate the basic limiter I think.

Have your users and you tried with dithering disabled? Maybe the Zero has enough oomph to do one but not both.

[JasonLG1979]

I put in a PR. My (soon to be documented) advice is that if you want at least some form of volume normalization on a Pi Zero v1.x use the basic mode. If it wasn't for the fact that there are a ton of Pi Zeros in the wild that are perfectly serviceable and Pi Zero v2's basically being unobtainium, I'd say just buy a Pi Zero v2. It would also save me from having to pull in the ancient ARMv6 P1/P0 toolchain. I could just use the libs in the standard Debian repo.

[removogel]

I had a try without Dither
librespot -v -n "MySpeaker" -b 320 -N --initial-volume 50 --device-type avr --dither none
The replay was fine for about 30 minutes, the again the known issue.

[2022-01-27T01:22:05Z TRACE librespot_playback::player] == Stopping sink ==
[2022-01-27T01:22:05Z TRACE librespot_connect::spirc] Sending status to server: [kPlayStatusPlay]
[2022-01-27T01:22:05Z INFO  librespot_playback::player] Loading <Pigs (Three Different Ones) [2011 - Remaster]> with Spotify URI <spotify:track:4gSiNltIPWhEMtxN8gQ9VG>
[2022-01-27T01:22:06Z DEBUG librespot_audio::fetch] Downloading file 88ef216c19f23f9289ecbc7c74781a03ba0f5f96
[2022-01-27T01:22:06Z INFO  librespot_playback::player] <Pigs (Three Different Ones) [2011 - Remaster]> (686346 ms) loaded
[2022-01-27T01:22:06Z WARN  librespot_playback::player] This track will at its peak be subject to 0.57 dB of dynamic limiting.
[2022-01-27T01:22:06Z WARN  librespot_playback::player] Please lower pregain to avoid.
[2022-01-27T01:22:06Z DEBUG librespot_playback::player] Normalisation Data: NormalisationData { track_gain_db: 2.577177047729492, track_peak: 0.6303134560585022, album_gain_db: 1.0692901611328125, album_peak: 0.8124434351921082 }
[2022-01-27T01:22:06Z DEBUG librespot_playback::player] Calculated Normalisation Factor for Track: 134.54%
[2022-01-27T01:22:06Z TRACE librespot_playback::player] == Starting sink ==
[2022-01-27T01:22:06Z TRACE librespot_playback::audio_backend::alsa] Desired Frames per Buffer: 15052
[2022-01-27T01:22:06Z TRACE librespot_playback::audio_backend::alsa] No Desired Period size in range reported by the device.
[2022-01-27T01:22:06Z TRACE librespot_playback::audio_backend::alsa] Buffer size: 15052
[2022-01-27T01:22:06Z TRACE librespot_playback::audio_backend::alsa] Desired Period Frame range: 1505 (Buffer size / 10) - 3763 (Buffer size / 4)
[2022-01-27T01:22:06Z TRACE librespot_playback::audio_backend::alsa] Actual Period Frame range as reported by the device: 940 - 941
[2022-01-27T01:22:06Z TRACE librespot_playback::audio_backend::alsa] Failed to set Buffer and/or Period size, falling back to the device's defaults.
[2022-01-27T01:22:06Z TRACE librespot_playback::audio_backend::alsa] You may experience higher than normal CPU usage and/or audio issues.
[2022-01-27T01:22:06Z TRACE librespot_playback::audio_backend::alsa] Actual Frames per Buffer: 15052
[2022-01-27T01:22:06Z TRACE librespot_playback::audio_backend::alsa] Actual Frames per Period: 940
[2022-01-27T01:22:06Z TRACE librespot_playback::audio_backend::alsa] Period Buffer size in bytes: 3760
[2022-01-27T01:22:06Z TRACE librespot_playback::audio_backend::alsa] Period Buffer capacity: 3760
[2022-01-27T01:22:06Z TRACE librespot_connect::spirc] Sending status to server: [kPlayStatusPlay]
[2022-01-27T01:22:06Z TRACE librespot_connect::spirc] ==> kPlayStatusPlay
[2022-01-27T01:22:07Z WARN  librespot_playback::audio_backend::alsa] Error writing from AlsaSink buffer to PCM, trying to recover, ALSA function 'snd_pcm_writei' failed with error 'EPIPE: Broken pipe'
ALSA lib pcm.c:8545:(snd_pcm_recover) underrun occurred
[2022-01-27T01:22:08Z TRACE librespot_connect::spirc] Sending status to server: [kPlayStatusPlay]
[2022-01-27T01:22:08Z TRACE librespot_connect::spirc] ==> kPlayStatusPlay
[2022-01-27T01:22:09Z WARN  librespot_playback::audio_backend::alsa] Error writing from AlsaSink buffer to PCM, trying to recover, ALSA function 'snd_pcm_writei' failed with error 'EPIPE: Broken pipe'```

[JasonLG1979]

There might be one thing we can do to make underruns more recoverable we could feed it a zero filled buffer so it would just play silence instead stuttering so much and crashing.

[roderickvd]

How would you approach that? That needs CPU cycles right when it's starved. Also you might want to stuff zeroes until the buffers are completely filled again. Transition from some PCM value to 0 will itself cause distortion.

[JasonLG1979]

How would you approach that?

When we get the 1st error message but before we call try_recover zero fill the buffer.

That needs CPU cycles right when it's starved.

Zero filling a Vec has got to be orders of magnitude less CPU intensive then actually processing that much audio.

Also you might want to stuff zeroes until the buffers are completely filled again.

More complicated than I really want to get.

Transition from some PCM value to 0 will itself cause distortion.

No worse than the dropouts you get during underruns.

The idea/hope is that maybe a zero filled buffer will give everything involved enough breathing room to pull their heads out of their butts.

What I'm thinking of would literally be just one extra line of code:

    fn write_buf(&mut self) -> SinkResult<()> {
        let pcm = self.pcm.as_mut().ok_or(AlsaError::NotConnected)?;

        if let Err(e) = pcm.io_bytes().writei(&self.period_buffer) {
            self.period_buffer.resize(self.period_buffer.capacity(), 0); // <- add this line.
            // Capture and log the original error as a warning, and then try to recover.
            // If recovery fails then forward that error back to player.
            warn!(
                "Error writing from AlsaSink buffer to PCM, trying to recover, {}",
                e
            );

            pcm.try_recover(e, false).map_err(AlsaError::OnWrite)?
        }

        self.period_buffer.clear();
        Ok(())
    }

[JasonLG1979]

To be clear it would not magically fix the problem. The idea is just to make underruns not completely tank the CPU. The hope is that it will help it recover. You'd still hear the dropout.

[JasonLG1979]

Nope, just tried that. Didn't work.

[mdekstrand]

Thanks for documenting this, @JasonLG1979. In the next update of the Alpine packages I'll add a comment to the configuration file pointing here for people using it on a Pi Zero (the Pi Zero is why I'm maintaining the Alpine package in the first place).