Dropouts when streaming via Roon to NAD C 658

Roon Core Machine

Apple Mac Mini, M1, 8GB RAM, macOS 12.3.1

Networking Gear & Setup Details

Google Wifi four-node mesh network

Connected Audio Devices

NAD C 658

Number of Tracks in Library

35,572 tracks

Description of Issue

I’m having a weird (and annoying) issue using Roon with my NAD C 658 streaming DAC-preamp, which is Roon Ready.

Here’s a description of my setup. The C 658 is in my main-floor living room, and the Apple Mac Mini that I use to run Roon Core is in my second-floor home office. I use Roon to play music from Qobuz and Tidal, and to play music from my own library, which is stored on a LaCie RAID system connected via Thunderbolt to the Mac Mini.

I have a four-node Google Wi-Fi mesh network. The Google Wi-Fi access point in my office is connected to my Internet router, and to the Ethernet port on the Mac Mini that runs Roon Core. Wi-Fi is turned off on the Mac Mini. I have another Google Wi-Fi access point on the equipment rack in my living room; it’s connected to the Ethernet ports on the C 658 and on the breakout box for my Samsung Frame TV.

Here’s the issue: When I stream to the C 658 from Roon, I get momentary dropouts. They’re frequent enough to be distracting. This happens with music streamed via Roon from Qobuz, as well as music stored on the RAID system connected to the Apple Mac Mini. But it doesn’t happen with music from Qobuz that I play through the C 658 using the BluOS app. So that would seem to rule out my network as the source of the problem.

But the dropouts don’t happen with music that I stream from Roon to other Roon Ready components in the same room as the C 658, so that would seem to rule out the Mac Mini as the source of the problem.

I have tried restarting my network several times, but that doesn’t help. The Google Home app reports that the Google Wifi access point in the living room has a “great connection.” I have even tried disconnecting the network cable from the C 658 and streaming to the C 658 via Wi-Fi instead. The dropouts persist. When I do this, I check the Wi-Fi signal strength in the Diagnostics menu of the BluOS app, and it’s either good or excellent. Software on all devices is up-to-date.

I’m posting this query on both the Roon Community and BluOS support forums. If anyone has any ideas or suggestions, I’d love to hear them. I’m stumped.

Roon places some pretty high performace requirements on your network, so it may still be a network issue. A few questions:

  • H
  1. How is the 658 connected to your network?
  2. How is the Mac Core connected to your network?
  3. How are the 4 Google WiFi nodes connected to your network and to each other?
  4. How many wireless devices are connected to your mesh network?

Google’s WiFi solution is good, but if you have a lot of devices on your network connected wirelessly, or many Google meshed access points connected to each other wirelessly, it may tax the capacity and latency of the overall network which may result in Roon’s temporary dropouts.

Thanks Robert. As outlined in my original post, the Mac Mini that runs Roon Core is connected via Ethernet to the primary Google Wifi access point, and the C 658 is connected via Ethernet to another Google Wifi access point in my living room. There are four Google Wifi nodes: the primary one in my office which is connected to the Internet router (which is in bridge mode) and the Mac Mini, and three additional nodes throughout my home (living room, kitchen, wife’s office). The nodes communicate wirelessly. There are 26 Wi-Fi devices: three computers (not including the Mac Mini), three smartphones, two printers, a smart thermostat, and various smart plugs and light switches.

Actually, that is not comparing apples to apples as the streams are totally different. When you stream from Roon, the music is sent to Roon Core and then processed into PCM which is then sent to the endpoint. PCM is a much larger stream and needs fast transfer times, any delays will cause dropouts. The BluOs app is sending the compressed audio file, prob flac.

Try and plug the Mac Mini to the router (instead of the Google WiFi access point) and see if that makes a difference.

1 Like

Gordon, thank you and helpful information. It seems your Core on the Mac Mini is connected to the primary Google WiFi router, so I believe that addresses one question from @Rugby. But as he states, there remains a higher load with Roon streaming across your network to your endpoint.

As the 658 basically is connected via WiFi through the other Google access point (due to the Google mesh node using WiFi to connect to the main Google router), I believe that is the issue, aligned with Rugby’s comments above. Google’s mesh system does not have a high capacity for network traffic, and with three nodes connecting wirelessly back to the main node, I believe it is straining the system at various times when you are streaming from Roon.

I recently tried to set up a Google WiFi mesh network at a friend’s house using three nodes (1 main Google WiFi device used as a router, and two wireless mesh nodes). While the network showed decent to good signal strength to connected devices, he went from a 600 Mbps wireless network to 20-80 Mbps due to the load on the Google mesh systems.

If the dropouts continue, and you cannot use Ethernet cables to connect any of the Google access points, one idea may be to upgrade to a larger capacity mesh system, preferably a tri-band system, which increases the capacity of the network for devices and traffic. This is what I needed to do for my friend’s network and he is seeing 600-800 Mpbs across his home again.

The other variable here is that the Roon Ready endpoint code has to be able to run on anything. Some devices are exceptionally capable with lots of memory and CPU and others can barely keep time (I wish I was joking on this one). We are very conservative with our buffer requirements as we can’t assume endless resources (and a longer buffer would create some ugly playback latency) so we only allocate enough to survive most minor network dropouts at the given bitrate.

In contrast BluOS can allocate much more memory since NAD controls the hardware and they can put in as much memory as is needed to meet their design specs. Furthermore since playback is initiated on the device itself (rather than the Roon core) latency is less of an issue. The end result is that BluOS is at an advantage as it can buffer an entire compressed file for playback which makes it less susceptible to network dropouts.

@Gordon_Brockhouse, based on the description of symptoms I’m suspecting that the mesh network is the root cause of your dropouts. Unfortunately, Google’s “everything is excellent” diagnostic message smooths over any rough spots when in reality any kind of RF interference at the right frequency (like a microwave or alarm motion sensor or even a vehicle driving by with active radar sensors) can be causing intermittent problems. Wi-Fi is convenient and tends to work great for “bursty” activity, but something needing a constant bitstream at a specific rate (like Roon) can be more susceptible to network issues.

Thanks Robert and Rugby. I understand that the bitrates of the PCM streams sent by Roon are larger than those of the FLAC files sent to BluOS. But I wonder if there’s more to my problem than that. Three points worth noting: 1. I can send 24/192 streams from Roon to other endpoints that I’ve had in my home without dropouts. 2. I can stream 4K video to my Samsung Frame TV, which is connected to the same access as the C 658 without dropouts. Those streams are much larger than the PCM streams that Roon is sending. 3. problem has developed in the past couple of months. Before that, I had no issues using Roon with the C 658.

That said, it may well be I need a new router. But I will have to have a mesh network, or use range extenders, because the Wi-Fi coverage in our home is uneven, especially in my wife’s office, and she needs a reliable connection for her work.

Gordon, understand. Regarding #1, and with no implicit knowledge, this may be a function of how the 658 buffers as Andrew noted. I believe that #2 is related to how video buffering occurs either on the TV or the streaming device used for the applications.

If you need to update your network, again I recommend a tri-band mesh system, examples from Netgear, ASUS, and others are good options.

If you have coax for cable TV or satellite in any of these rooms then you might want to look into MoCA or DECA as a solution here. I had to go down this path in an old house and it worked exceptionally well. IIRC you don’t have to have cable or satellite service as you can get injectors and endpoints that will work standalone.

1 Like

Thanks everyone for your help and suggestions. Actually, the problem was unrelated to my network or Roon server. Lenbrook support examined the C 658’s diagnostic logs, and saw that my C 658 was constantly trying to reconnect to a non-functioning network share location. I had forgotten about setting up this share, which is when the problem began. Lenbrook support thought these reconnection attempts and resultant authentication failures might be interrupting the Roon stream. They were right. Per their suggestion, I deleted that share (which I do not need), and all is good.


This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.