04-01-2025, 03:00 PM
An audio glitch like a dropout can occur when network latency gets really high and the playback device buffer runs out of audio data.
In a ping test the latency would show up something like below in the fictitious sample data.
64 bytes from 192.168.1.1: icmp_seq=2185 ttl=64 time=4.03 ms
64 bytes from 192.168.1.1: icmp_seq=2186 ttl=64 time=800 ms
64 bytes from 192.168.1.1: icmp_seq=2187 ttl=64 time=3.97 ms
64 bytes from 192.168.1.1: icmp_seq=2188 ttl=64 time=600 ms
64 bytes from 192.168.1.1: icmp_seq=2189 ttl=64 time=3.29 ms
64 bytes from 192.168.1.1: icmp_seq=2190 ttl=64 time=700 ms
64 bytes from 192.168.1.1: icmp_seq=2191 ttl=64 time=3.28 ms
^C
--- 192.168.1.1 ping statistics ---
x packets transmitted, x received, 0% packet loss, time y ms
rtt min/avg/max/mdev = 0.821/300/800/376.6 ms
pi@moode9:~ $
What the data means is that on average it took 1/3 of a second for a network data packet to make the round trip from sender to receiver and in one case almost 1 full second. This amount of latency is more than enough to cause playback device buffer starvation.
In a ping test the latency would show up something like below in the fictitious sample data.
64 bytes from 192.168.1.1: icmp_seq=2185 ttl=64 time=4.03 ms
64 bytes from 192.168.1.1: icmp_seq=2186 ttl=64 time=800 ms
64 bytes from 192.168.1.1: icmp_seq=2187 ttl=64 time=3.97 ms
64 bytes from 192.168.1.1: icmp_seq=2188 ttl=64 time=600 ms
64 bytes from 192.168.1.1: icmp_seq=2189 ttl=64 time=3.29 ms
64 bytes from 192.168.1.1: icmp_seq=2190 ttl=64 time=700 ms
64 bytes from 192.168.1.1: icmp_seq=2191 ttl=64 time=3.28 ms
^C
--- 192.168.1.1 ping statistics ---
x packets transmitted, x received, 0% packet loss, time y ms
rtt min/avg/max/mdev = 0.821/300/800/376.6 ms
pi@moode9:~ $
What the data means is that on average it took 1/3 of a second for a network data packet to make the round trip from sender to receiver and in one case almost 1 full second. This amount of latency is more than enough to cause playback device buffer starvation.
