Snapclient hangs

[zhicks]

I'm seeing an issue where audio plays for maybe 10 minutes on a Raspberry Pi B, then stops with no warning or message half the time, where other times I get an XRUN message.

I am running snapserver on an Ubuntu computer with ethernet, and I'm also running snapclient on that computer. That instance of snapclient does not hang, but the Pi running snapclient does eventually hang.

I am using a Pulse Audio sink as specified in the readme. Both snapserver and snapclient report an audio format of 44100:16:2. I am running both snapclients with PULSE_LATENCY_MSEC=60, from issue #16, and I am also running with --latency 750 on the Pi, which I've noticed tends to sync just right with the main computer.

This is the latest version of snapcast, pulled from git and made from source. Here is what the Pi reports - looks normal until it suddenly hangs (and then I have to issue Ctrl+\ to get it to quit):

...
2016-02-01 07-00-56 [out] Chunk: 4 4 10 4 500 80
2016-02-01 07-00-57 [out] Chunk: 5 5 5 5 500 71
2016-02-01 07-00-58 [out] Chunk: 1 4 5 5 500 67
2016-02-01 07-00-59 [out] Chunk: -8 -7 4 4 500 68
2016-02-01 07-01-00 [out] Chunk: 3 -1 -1 4 500 67
2016-02-01 07-01-01 [out] Chunk: 0 3 -1 4 500 56

Whereas the server gives no indication anything has frozen up. Any recommendations? Could it be the --latency 750 setting on the Pi?

[zhicks]

To answer my own question, it is the latency setting on the Pi. Running without latency avoids this problem, but it's out of sync at that point - so running with the latency setting and then running snapserver with a higher buffer lessens the chance of the problem occurring. I'm still not sure if there's a setting on the Pi for sound card latency that can be changed, although 750 seems to be the magic number.

[badaix]

Latency of n means that the device has a latency of n ms and so the Snapclient tries to play out by n ms earlier. The standard buffer size is 1000ms.
If you configure the latency to 750ms, the effective buffer size is reduced to 250ms, which seems to be critical and leads to alsa buffer underruns.
You can either raise the buffer on the server (-b or --buffer) to e.g. 1500 or configure a negative latency on your main computer --latency -750