I have one PI Zero running latest snapserver and snapclient. And another PI Zero runing the client.
The audio syncronitzation work fine but every few seconds or minutes the sound drop one instant (less 1 second) on all Pi clients. The wifi sems work fine.
I changed the buffer and streamBuffer values on snapserver but I'm still with audio drops.
How I debug the snap connection to find the cause?
Could you explain the buffer and streamBuffer parameters and their differences?
Thanks for this great project.
calanor
>All comments
Buffer [ms] (default 1000ms) is the total buffer size (or better buffer duration) between recording the signal on the server and playing it out on the client. This can be translated directly to the total latency of the audio signal: if you press play or pause or skip a track, you will always notice a delay of 1000ms because of this buffer.
Drop outs should be caused in most cases by an empty buffer. Sometimes I can see in my router statistics huge traffic causing kind of "flooding" (I guess they are caused by retransmissions).
Snapcast is TCP based and so single packets might be retransmitted if they were lost or completely out of order, or having the wrong checksum, ... (and nope, it would be hard to move to UDP :) )
If you're facing drop outs, you can try to make this buffer larger. You can try to find out the root cause (no TCP packets, or duplicated and retransmitted packets, ...) by using tcpdump or wireshark on your client and/or server.
The streamBuffer [ms] (default 20ms) is less interesting. It means that the server should read PCM data chunks of this duration (from the pipe) before passing it to the encoder. So the server is reading continuously 20ms of audio data and is feeding these chunks into the FLAC encoder. The encoder might itself buffer the chunks because it needs a certain amount of audio before encoding it (this is the encoder delay), which is in case of FLAC is ~26ms (ogg vorbis needs ~200ms AFAIK). So a streamBuffer of 20ms is a good choice.
When using PCM codec on the server, you will not have any encoder delay. Using a small streamBuffer of e.g. 1ms would cause 1000 small TCP packets per second, causing overhead introduced by the ethernet/TCP packet overhead (small amount of payload and relatively big amount of header data)
To summarize: you can play around with the Buffer size, reboot your router, sniff the traffic with tcpdump, maybe check with top if you maybe have CPU load problems.
badaix
on 2 Apr 2017
Related issues
dantheperson
路
4Comments
tgurr
路
7Comments
artmg
路
3Comments
qhello
路
3Comments
klundry
路
7Comments
Most helpful comment
Buffer [ms] (default 1000ms) is the total buffer size (or better buffer duration) between recording the signal on the server and playing it out on the client. This can be translated directly to the total latency of the audio signal: if you press play or pause or skip a track, you will always notice a delay of 1000ms because of this buffer.
Drop outs should be caused in most cases by an empty buffer. Sometimes I can see in my router statistics huge traffic causing kind of "flooding" (I guess they are caused by retransmissions).
Snapcast is TCP based and so single packets might be retransmitted if they were lost or completely out of order, or having the wrong checksum, ... (and nope, it would be hard to move to UDP :) )
If you're facing drop outs, you can try to make this buffer larger. You can try to find out the root cause (no TCP packets, or duplicated and retransmitted packets, ...) by using tcpdump or wireshark on your client and/or server.
The streamBuffer [ms] (default 20ms) is less interesting. It means that the server should read PCM data chunks of this duration (from the pipe) before passing it to the encoder. So the server is reading continuously 20ms of audio data and is feeding these chunks into the FLAC encoder. The encoder might itself buffer the chunks because it needs a certain amount of audio before encoding it (this is the encoder delay), which is in case of FLAC is ~26ms (ogg vorbis needs ~200ms AFAIK). So a streamBuffer of 20ms is a good choice.
When using PCM codec on the server, you will not have any encoder delay. Using a small streamBuffer of e.g. 1ms would cause 1000 small TCP packets per second, causing overhead introduced by the ethernet/TCP packet overhead (small amount of payload and relatively big amount of header data)
To summarize: you can play around with the Buffer size, reboot your router, sniff the traffic with tcpdump, maybe check with
topif you maybe have CPU load problems.