Has anyone else come across issues when using a Rasberry Pi 3b+ with USB devices?
I have tried 2 different 3b+ Pi’s on both my Project S2 & MyTek Brooklyn and when playing back MQA material it clicks and looses sync. Tested with both Ropieee and DietPi OS just to be sure.
Swapped back to an earlier Pi 3b and it works perfectly. It’s just the latest plus model that is causing a problem.
Any suggestions?
Thanks
Duncan
Not enough power?
Don’t think so, it’s a 25va 5v linear PSU (also tested with 16v PSU in to a justboom Amp to power it)
Both DAC’s are self powered.
Pi appears to be running fine.
Use WiFi connect to network instead of LAN
Thanks @Eric_Ho that fixed it; though moving from Wired Lan to Wireless is a backwards step for me.
I can only assume that the USB not liking the addition throughput of the 1Gb Lan card.
I’ll try it again wired, but limit the switch port to 100mbs.
Hi @Eric_Ho. Can you provide any idea as to why the wired -vs- wireless network connection should make any difference? As a side note, I have been experiencing the same issues but switched to using the HDMI output of the Pi with good results. Something in the drivers or is it some sort of hardware malady that causes the clicking noises when streaming through USB?
The ethernet port shared the same bus as the usb so it causes some issues. WiFi does not.
True regarding the Pi 3B+ but doesn’t explain this:
What sample rates? Only PCM192kHz and below?
At 44khz it causes MQA to drop out; hence you can see the problem, at 96khz to can really hear it popping/clicking a few times a second.
I will try forcing the network to 100mbs as it might just be the 1gig network saturating the bus for very short periods.
The 3b+ got a gigabit network card, but the real throughput is limited to about 300mbs because of the USB bus it’s connected by. The 3b is only 100mbs so in theory cannot saturate the bus.
I’ve move it now to have a justboom hat instead and not a single dropout, pop or click. Which does kinda confirm a usb bus issue…
I might be getting somewhere with more digging…
https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=208512&p=1297857#p1297857
There appears to be a known issue if your network switch has flow control disabled; and checking mine it is disabled. I’ll enable and do some further testing on Sunday.
@duncan, please share your findings. Based on the explanation in the link you provided restricting the port to 100Mbps should help too. I wonder what solution you chose.
Setting the port to 100mbs and/or enabling Flow Control made no difference.
When playing it appears to be stable for the first 4-5 seconds before it repeatably drops out of MQA / clicking or non MQA.
As a second test, on the same Pi I installed a JustBoom Dac HAT at the same time as the USB Dac. Played music to both and Justboom was perfect - USB dac was exactly the same with MQA dropping out after 4-5 seconds.
Next I will try an old school Netgear 10/100mbs switch to rule out my Ubituiti manage switch.
So @G_P, with the old school Netgear 10/100Mbs switch it worked perfectly.
I installed it in between my Unifi Switch and the Pi - so just adding another switch to the chain.
So it appears the Pi with its new 1Gbs Network does not like my unifi US-48 switch; I’ll dig around with the settings on the switch a bit more.
I wonder if you can force the Pi to only connect at 100mbs?
@duncan, I appreciate your testing efforts and thanks for opening my eyes about the Pi 3B+ problems. I have a Pi 3B+ but it is running Pi-hole and Ubiquiti controller, so I can’t test it for audio. I was thinking about getting one or two more 3B+ Pis to use as Roon endpoints but now I am thinking maybe I should get 3B instead, although I’d prefer the 3B+ because of its 5GHz wifi capability in case I decide to use it in the future.
I did some testing on my 3B+ without audio. Mine is connected to a Linksys managed switch. When I checked port statistics I saw a bunch of errored and dropped packets on this port. I had never seen those on my network before. The port was gigabit with auto negotiation. Then I tried to set it to 100M full duplex. I checked the Pi and it connected 100M half duplex even after reboot, and the flow control on the Pi was disabled while enabled on the switch. Maybe that’s why you didn’t see the difference when you forced the port to 100M – the Pi has its own mind. I found that if I change “Auto advertisement” from “Max capability” to “100 Full Duplex” the Pi behaves and connects at 100M full duplex with flow control. I don’t know if your switch has similar options. And I just found an explanation to this: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=208512&p=1297857#p1294761 “things should default to 100/Half if autonegotiate is turned off”.
By the way, you can see the information about the Pi connection using this command ‘ethtool eth0’ but you need to install the ethtool first: ‘sudo apt-get install ethtool’. You can see the network statistics using this command: ‘ifconfig’.
I think I found the ultimate solution in the link you provided: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=208512&p=1297857#p1294790 “Simply insert the following into /etc/rc.local: ‘/sbin/ethtool -s eth0 speed 100 duplex full autoneg on’". After reboot this will limit the network interface to 100M full duplex with auto negotiation enabled. I tried it and my Pi connects now at 100M full duplex and flow control enabled. I still see dropped RX packets though [EDIT2: After some investigation I found out that seeing some dropped RX packets is normal for various reasons]. I wonder if you want to try this without your extra 10/100 switch and see if it works for audio. I think it should.
EDIT: Found that disabling EEE (Energy Efficient Ethernet) further helps with network problems: add ‘dtparam=eee=off’ to /boot/config.txt https://forum.openmediavault.org/index.php/Thread/18991-New-approach-for-Raspberry-Pi-OMV-images/?postID=171929#post171929 Seems like the Pi 3B+ is a mess.