Dropouts under a very weird condition

[SerbJ]

I am running a Pi4B with a USB Thumbdrive on the 3.0 bus, and USB DDC on the 2.0 bus.  It is feeding DACs in a Yamaha Aventage 2060.  Before that a HK 520.  Thumbdrive is a "high speed" type and has around 630 Cd's worth of FLAC files.  I have had about a dozen dropouts of about 0.5sec, all within the last year.

I noticed this first when I was still running Moode 8.x.x and just today got one occurance with 9.3.0 Moode w/ 0.24.2 MPD.  This is also a new PI4B with a different USB thumbdrive.  

So here comes the crazy part.  All of these dropouts occured when I sat the iPad down on the chair and got up to do something!   I have tried to replicate it many times without one success.  It only happens when I'm not expecting it.  I have never heard a dropout just sitting there.  And no, this is not an early April Fools joke. 

Struggling to even come up with a rational scenerio.  The Pi and the ipad are on the 5G WAN.  The router is not in direct view.  It is two rooms over.  I thought somehow I was interfering with the 5G, but doesn't really explain why the dropout.  I can switch the ipad between 5G and 2.4G while music playing, no issues.  I am fairly certain it is not happening on a screen refresh, or wake from blank screen.  I've done that many times trying to cause it.  It will be a pain to move the router into the same room, but running out of things to try.  Also have a new DDC and USB cable coming.  The infrequent occurance doesn't help.

Are there runtime logs I can view?  Or is that only when that debug is turned on in the System Config menu?  and from the warning, might cause its own problems.

[DRONE7]

As it happens so infrequently that will be a hard one to figure.
Are you able to run one system without the DDC? (what make model is it?) as that seems to be the odd item specific to your setup.

Perhaps (if any) others using a DDC can comment.

As far as 'putting down the iPad' causing dropout I would suspect RFI affecting a component (DDC?).
Perhaps hold the iPad near your setup and move it about in different orientations and see if you can reproduce the dropout.

[SerbJ]

As it happens so infrequently that will be a hard one to figure.
Are you able to run one system without the DDC?  (what make model is it?) as that seems to be the odd item specific to your setup.

Perhaps (if any) others using a DDC can comment.

As far as 'putting down the iPad' causing dropout I would suspect  RFI affecting a component (DDC?).
Perhaps hold the iPad near your setup and move it about in different orientations and see if you can reproduce the dropout.

I think many people call them USB DACs, but really just a Digital to Digital Convertor.  It is Douk Audio U2 PRO, running on its own linear power supply.  I also had used an old Peachtree X-1, but can't remember if it happened with it or not. It is at camp, so can't swap that out now.  I can't feed the DACs in the AVR without it.  

I will try moving the iPad closer and see what that does.   I'll put it right up and touching the Pi, DDC, and AVR.   I wouldn't think that was the trigger at 6' away from all the electronics in the cabinet.  Its has happened with different iPads, as well.  But, something to try.

[SerbJ]

If there is a good FAQ or Guide on the different error logs, please point me in the right direction. I did find the MPD log. No logged errors during the timeframe of the dropout, just each song as it was played. It did have some errors latter, but it is seperate issue than this, that was probably operator error.

[Tim Curtis]

The symptom "I have had about a dozen dropouts of about 0.5sec, all within the last year." suggests a network issue.

The way to troubleshoot this type of issue is to run a ping test from the Pi to your Router and then examine the ping times while it's running and then the final stats after terminating it. 

Ideally the ping times will be consistent for example around 3 or 4 ms for WiFi over an arbitrarily long sample period. If they vary a lot and by wide margins it could indicate a signal quality or signal strength issue. The final ping stats will reflect this by showing long average round trip time (rtt) and high standard deviation (mdev).

A good ping test result will look something like below. This one ran for about 35 minutes.

.
.
64 bytes from 192.168.1.1: icmp_seq=2167 ttl=64 time=3.95 ms
64 bytes from 192.168.1.1: icmp_seq=2168 ttl=64 time=3.96 ms
64 bytes from 192.168.1.1: icmp_seq=2169 ttl=64 time=0.946 ms
64 bytes from 192.168.1.1: icmp_seq=2170 ttl=64 time=3.95 ms
64 bytes from 192.168.1.1: icmp_seq=2171 ttl=64 time=5.78 ms
64 bytes from 192.168.1.1: icmp_seq=2172 ttl=64 time=3.05 ms
64 bytes from 192.168.1.1: icmp_seq=2173 ttl=64 time=1.08 ms
64 bytes from 192.168.1.1: icmp_seq=2174 ttl=64 time=4.11 ms
64 bytes from 192.168.1.1: icmp_seq=2175 ttl=64 time=3.85 ms
64 bytes from 192.168.1.1: icmp_seq=2176 ttl=64 time=3.94 ms
64 bytes from 192.168.1.1: icmp_seq=2177 ttl=64 time=4.62 ms
64 bytes from 192.168.1.1: icmp_seq=2178 ttl=64 time=3.93 ms
64 bytes from 192.168.1.1: icmp_seq=2179 ttl=64 time=3.92 ms
64 bytes from 192.168.1.1: icmp_seq=2180 ttl=64 time=4.07 ms
64 bytes from 192.168.1.1: icmp_seq=2181 ttl=64 time=4.65 ms
64 bytes from 192.168.1.1: icmp_seq=2182 ttl=64 time=3.96 ms
64 bytes from 192.168.1.1: icmp_seq=2183 ttl=64 time=3.96 ms
64 bytes from 192.168.1.1: icmp_seq=2184 ttl=64 time=3.95 ms
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=5.97 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=3.19 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=3.95 ms
64 bytes from 192.168.1.1: icmp_seq=2191 ttl=64 time=3.28 ms
^C
--- 192.168.1.1 ping statistics ---
2191 packets transmitted, 2191 received, 0% packet loss, time 2194796ms
rtt min/avg/max/mdev = 0.821/4.205/62.377/3.098 ms
pi@moode9:~ $ 

As @DRONE7 hinted at, WiFi is susceptible to signal interference for example some device near the sender or receiver is emitting radiation that degrades the signal or there are materials between the sender and receiver that attenuate the signal, etc.

[SerbJ]

The symptom "I have had about a dozen dropouts of about 0.5sec, all within the last year." suggests a network issue.

The way to troubleshoot this type of issue is to run a ping test from the Pi to your Router and then examine the ping times while it's running and then the final stats after terminating it. 

Ideally the ping times will be consistent for example around 3 or 4 ms for WiFi over an arbitrarily long sample period. If they vary a lot and by wide margins it could indicate a signal quality or signal strength issue. The final ping stats will reflect this by showing long average round trip time (rtt) and high standard deviation (mdev).

A good ping test result will look something like below. This one ran for about 35 minutes.

.
.
64 bytes from 192.168.1.1: icmp_seq=2167 ttl=64 time=3.95 ms
64 bytes from 192.168.1.1: icmp_seq=2168 ttl=64 time=3.96 ms
64 bytes from 192.168.1.1: icmp_seq=2169 ttl=64 time=0.946 ms
64 bytes from 192.168.1.1: icmp_seq=2170 ttl=64 time=3.95 ms
64 bytes from 192.168.1.1: icmp_seq=2171 ttl=64 time=5.78 ms
64 bytes from 192.168.1.1: icmp_seq=2172 ttl=64 time=3.05 ms
64 bytes from 192.168.1.1: icmp_seq=2173 ttl=64 time=1.08 ms
64 bytes from 192.168.1.1: icmp_seq=2174 ttl=64 time=4.11 ms
64 bytes from 192.168.1.1: icmp_seq=2175 ttl=64 time=3.85 ms
64 bytes from 192.168.1.1: icmp_seq=2176 ttl=64 time=3.94 ms
64 bytes from 192.168.1.1: icmp_seq=2177 ttl=64 time=4.62 ms
64 bytes from 192.168.1.1: icmp_seq=2178 ttl=64 time=3.93 ms
64 bytes from 192.168.1.1: icmp_seq=2179 ttl=64 time=3.92 ms
64 bytes from 192.168.1.1: icmp_seq=2180 ttl=64 time=4.07 ms
64 bytes from 192.168.1.1: icmp_seq=2181 ttl=64 time=4.65 ms
64 bytes from 192.168.1.1: icmp_seq=2182 ttl=64 time=3.96 ms
64 bytes from 192.168.1.1: icmp_seq=2183 ttl=64 time=3.96 ms
64 bytes from 192.168.1.1: icmp_seq=2184 ttl=64 time=3.95 ms
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=5.97 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=3.19 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=3.95 ms
64 bytes from 192.168.1.1: icmp_seq=2191 ttl=64 time=3.28 ms
^C
--- 192.168.1.1 ping statistics ---
2191 packets transmitted, 2191 received, 0% packet loss, time 2194796ms
rtt min/avg/max/mdev = 0.821/4.205/62.377/3.098 ms
pi@moode9:~ $ 

As @DRONE7 hinted at, WiFi is susceptible to signal interference for example some device near the sender or receiver is emitting radiation that degrades the signal or there are materials between the sender and receiver that attenuate the signal, etc.

Thx Tim.  That does help allot.  I thought it might be the network, but only a wild theory on my part.  It is great to hear it from you, before going down that rabbit hole.  I didn't know it could cause a drop out.  The electronics are in the back corner of the room.  I think when I checked the signal strength on the Network config screen it showed around 63%.  

I will do the ping tests and get a few different baselines.  Then when it happens again, I can run it shortly after to see/compare.  

Should I do from the iPad to the router, as well?  

PS: Other devices were slow on the network ths AM.  A router and cable modem reboot brought it back.  So, could have been impacting it yesterday.  At least, things are seeming to congeal around the network.  The 5G band only has two TVs on it, besides the Pi and this iPad.  Neither was on yesterday, though.  

Anway, I'll keep the thread updated as I collect data.  Thx again.

[TheOldPresbyope]

@SerbJ

You didn't say in your first post whether the dropouts you experienced occurred when you were playing local files from the attached USB thumbdrive or when you were streaming audio from a remote source. I assumed it was with local files when I read it.

The first thing which comes to mind when I hear of a "dropout" is the momentary silencing which occurs when MPD experiences an underrun error. These errors get logged to the file /var/log/mpd/log. Off the top of my head, I don't recall if the MPD log level has to be pushed to "verbose" to see them. That setting can be found in the m> Config > Audio > MPD settings subpanel of the moOde webUI.

Mind you, the logs fill up from normal information and are cleared periodically so you may not easily catch unicorn events that way.

Regards,
Kent

[Tim Curtis]

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.

[Tim Curtis]

@SerbJ

You didn't say in your first post whether the dropouts you experienced occurred when you were playing local files from the attached USB thumbdrive or when you were streaming audio from a remote source. I assumed it was with local files when I read it.

The first thing which comes to mind when I hear of a "dropout" is the momentary silencing which occurs when MPD experiences an underrun error. These errors get logged to the file /var/log/mpd/log. Off the top of my head, I don't recall if the MPD log level has to be pushed to "verbose" to see them. That setting can be found in the m> Config > Audio > MPD settings subpanel of the moOde webUI.

Mind you, the logs fill up from normal information and are cleared periodically so you may not easily catch unicorn events that way.

Regards,
Kent

Oops I think it was file from a locally attached USB drive. In that case audio glitches are not network related.

Yes, look at MPD log for XRUNs.

[the_bertrum]

Could it be as simple as a loose USB socket? I have a thumb drive that will dip out and back in again, just enough to bork a file transfer but not enough to unmount and I put this down to the fact it is less "snug" in the socket than any other drives I have.