I’m looking for suggestions for a complete Endpoints which includes Pi , DAC and Amplifier.
I’ve successfully run a RoPieee network for many years, based on Pi 3 and both Hifiberry DAC+ plus Amp and Allo Boss kit.
I have a miniDSP and high end kit in my lounge but the Pis provide a flat wide synchronised music solutions.
Of late though network issues seem to be causing issues stopping playback. Roon reports Qobuz network issues, but playing to just one end point doesn’t cause any issues. One of those endpoints is WiFi based , the others wired.
So I’m looking for either advice on upgrading the pi to support WiFi properly or replacing the endpoints
I’d love to be able to trace exactly where the issue is. The Roon logs identify buffer issues which I assume means endpoint network issues rather than external network problems but if there’s anything in the RoPieee logs that would tie it down that would be great
WiFi is the weakest link, if you playing synchronized endpoints you really need solid connections via wired lan. Especially if your WiFi is also being used for other things like family or even connection for the core remote which is probably not helping either.
Damn, one of my end points is some distance from a network point. Something I should have thought about before the bedroom renovations.
Would a separate WiFi dongle and perhaps a separate subnet help. When I last upgraded my router I implemented dual band Smart Control. Segmenting 5 and 2.4 ghz. Generally useful but perhaps not on the Pis
Try running a cat 5 or 6 cable over the floor to the offending endpoint and reboot to get the lan working then see how things play out without committing a dedicated route for a cable.
Different subnets won’t work as roon needs everything on one subnet and other WiFi channels or SSID’s won’t buy much either.
You need to understand that WiFi is not a full duplex transmission and suffers much from interference from other WiFi and transmissions in the area causing many errors and retransmission which is fine for normal data but not for audio where edit sync timing (not music clocking) signal is also being transferred. As a remote this is fine but not so great for an endpoint.
This is absolutely wrong - no audio clocking relevant information is being transmitted over neither WiFi nor wired Ethernet connections.
It’s more about connection speed and stability, short data buffers used in Roon, mainly due to enable tighter group syncing, and of course, as you rightfully state, WiFi’s disadvantage of not being full duplex.
BTW, I run two RPi3B+ over 5GHz WiFi with red book and hires up to 192kHz/24bit for years without any drop outs ever.
Also, the unit in the kitchen has never been jammed by the microwave running in between it and the router.
One unit runs HiFi-Berry OS and the other a regular RPi OS distribution.
Had also used DietPi and Ropieee in the past, but less reliably so.
Microwave ovens use electro-magnetic radiation in (or close to) the 2.4GHz band and thus tend to cause more issues with the 2.4GHz Wifi band which tends not to be used so much these days because it is bandwidth limited. 5GHz (and now 6GHz) frequencies are not employed by Microwave ovens (and the way that the EMR is generated means that there is very low harmonic content).
The reason that both the Microwave oven and 2.4GHz WiFi use 2.4GHz (or thereabouts) is because this is the water absorbtion band. This is by design because in both cases it confers advantages. This means that:
Microwave ovens can heat the cooking foodstuff because the water content is heated by the emiited electro-magnetic radiation. A 1GHz (or even a 3GHz) microwave oven would not heat your food very well.
WiFi signals are also attenuatted by the water content in the air - which is (usually) a good thing because it means that my WiFi, and that of my neighbours some distance away, do not interfere with each other because of the limited range of WiFi (although the inverse square law of received power vs distance also contributes to this).
Having ungrouped the three endpoints the two wired ones seem to be happily working together.
As a matter of interest I also used a Pi with a display to display what’s playing. It has no audio output. I assume the same network issues would apply to that as well
Well timing and sync info certainly is as i understand it. It’s part of RAAT. No of course the music data clocking is not as that is done at the dac level - edited my post to make that clearer I hope.
Wifi is a fickle thing when timing with other devices is needed. It’s often fine stand alone but not always even then depending on what else is going on on the network.
Run the test with the endpoint and lan connection to troubleshoot
Yes, Roon server logs should show the zone sync situation. I don’t have (currently) grouped play logs, but here’s a typical Roon Server log entry that shows the server tracking sync with an endpoint:
12/24 20:28:50 Trace: [Tivoli Study] [zoneplayer/raat] sync iFi ZEN Stream (Soekris dac1xxx USB Audio 2.0): realtime=39829620176398 rtt=1000us offset=36895332176us delta=545us drift=-30262us in 1395.833s (-21.681ppm, -78.051ms/hr)
In the RAAT protocol, the server sends some kind of track timestamps to the endpoints, and receives back information about how far the endpoints have progressed in playing the track, so that it can adjust play rate across endpoints to ensure synchronous play. If anything delays those back messages too much, the Roon server gives up. WiFi networks are subject to bursty packet loss from from conflict with other devices in the same network or with other networks. Those bursts are short enough not to bother normal Web use, but are long enough to disrupt RAAT. I’ve investigated this some time ago with ad-hoc network measurements that showed video calls over WiFi saturating the network briefly and causing enough TCP retransmits to make the Roon server give up on tracks playing to a WiFi endpoint.
(Some other video and audio streaming protocols handle the problem by just not trying to maintain lossless and perfectly synchronized streams, hoping that watchers/listeners are too distracted by their phones to not even notice…)
I’ll try a wired connection. Somewhere i’ve got a couple of old powerline adapters. That should prove the case. If that fixes it I’ll think through a more permanent solution without the powerline.
I’ve been running two wired endpoints all day without issue and no buffer errors in the log. That certainly suggests the wireless endpoint is the issue.
Yes, they’re all grouped together, and I’m simply connecting them to my 5GHz network via their on-board dual-band WiFi chip - see RPi3B+ datasheet here.
See screenshot with proof …
Thanks for the lecture, Wade, appreciate it.
I’ve actually been aware of all that, but had overlooked to mention that I’d tested with 2.5GHz WiFi for the sake of the argument in this forum, where members claim having problems caused by their microwaves and me suggesting to replace such damaged units leaking HF.
Configured the 3 endpoints to run wired last night and rang a test using the roon radio function to randomly select Qobuz tracks without error for over 8 hours.
As a matter of interest what should I be looking for in the roon server log to identify possible end point issues. I see trace, debug and info messages.
How did you enable the 5gHz on the RPi3B+. I found one but after installing Ropieee it only connects to the 2.4ghz network. I too have a ASUS router if it’s a router config item
I’ve given up on WiFi for my rpi endpoints pretty much no issues ever wired and often pauses with WiFi so just give up…external WiFi dongles probably fare better tho in my experience.
