Clients go out of sync after silence in source material

[fatg3erman]

Describe the bug I have 3 clients. All Raspberry Pis. One is also running the snapserver and Mopidy. My snapserver is fed from Mopidy via an ALSA loopback device. I'm encountering issues when playing certain sources that the 3 clients go out of sync briefly, but only after a short period of silence in the source material.

When this happens I see errors on all 3 clients simultaneously, for example after a short silence (< 1s) pMiniBuffer->full() && (abs(pMiniBuffer->mean()) > 50) and after a slightly longer silence

Exception: Not enough frames available, requested frames: 3899, available: 882
Failed to get chunk
XRUN while waiting for PCM: Broken pipe

When the silence ends all 3 clients are out of sync for a moment before they come back into sync again. I've read all the other reports about handling those kinds of errors but no matter what I change it makes no difference - it's is definitely related to the sliences in the source material.

Steps to Reproduce

1. Play a file which has a section of complete silence of around 1s. I've used Mopidy and FFMpeg to play such a file into the ALSA loopback device.

Environment details Snapcast 0.27 from the packages you supply Raspbian bullseye.

Mopidy Output Config

output = audioresample ! audioconvert ! audio/x-raw,rate=44100,channels=2,format=S16LE,quality=10 ! alsasink device=hw:0,0,0
mixer=software

Snapserver Stream Config (all other values at default)

stream = alsa://?name=RompR&device=hw:0,1,0
sampleformat = 44100:16:2
codec = pcm

stream = airplay:///usr/local/bin/shairport-sync?name=Airplay

stream = meta:///RompR/Airplay?name=Multiroom

snapclient 1 (running on the server, Pi 4B) SNAPCLIENT_OPTS="--player alsa:buffer_time=120 --soundcard=hw:CARD=BossDAC,DEV=0 --mixer=hardware:Digital"

snapclient 2 (Pi Zero) Seems to need --latency 20 or it's noticeably behind SNAPCLIENT_OPTS="--latency-20 --player alsa:buffer_time=120 --soundcard=hw:CARD=BossDAC,DEV=0 --mixer=hardware:Digital"

snaclient 3 (Pi 3B with USB sound card fixed at 48KHz hence using plughw) SNAPCLIENT_OPTS="--player alsa:buffer_time=120 --soundcard=plughw:CARD=StealthBar,DEV=0"

[fatg3erman]

I've done some more investigation into this and here's what I know so far:

1. It's only certain source files that cause this. Almost all my media plays without dropouts, but specific sources - notably podcasts from acast.com - will do this reliably even if I download them and play them as local files.
2. It's not Mopidy. I used Audacity to edit out a short chunk of a problematic file and played it locally using ffmpeg, piping the ffmpeg output to the ALSA loopback and was able to reproduce the problem.
3. Setting the sample rate of the snapcast streams to 48KHz did not help.
4. Using plughw instead of hw for the snapclients did not help.
5. At the point in the source file where I'm seeing this behaviour there is complete silence - all samples on both channels are 0 for a period of roughly 1s.

So at present I'm unsure if this is a snapcast issue or an ALSA issue with the loopback device.

[fatg3erman]

As a final test I took the file I can play with ffmpeg to reproduce the problem and used Audacity to insert some almost inaudible white noise over the silent section. When I pay this file I get no dropouts and all the clients stay in sync, which confirms that it is the silences in the source that are the cause of the issue.

[mawe42]

I noticed the same behaviour and used the idle_threshold parameter for my sources as a workaround. I.e. something like this: source = alsa:///?name=Channel1&device=out1&sampleformat=48000:16:1&idle_threshold=2000

[fatg3erman]

Thank you! That seems to have worked. That option is very well hidden. I guess I should close this.