Issue after switching to Nucleus

Roon Core Machine

Previous Core:
MB PRO specs
3.5 GHz Dual-Core Intel Core i7
Intel Iris Plus Graphics 650 1536 MB
16 GB 2133 MHz LPDDR3
OSX 13.1 Ventura

Current core with issues:
Roon Nucleus rev B
Roon Version 2.0 (build 1148)
RoonOS Version 1.0 (build 254)
OS Version Roon OS 1.0 (build 175) stable

Networking Gear & Setup Details

ISP Xfinity Gigabit 1.2gbps
Home wired with CAT6
Router Asus RT-AX88U (no switch between router and Nucleus or RS150B) CAT6

Connected Audio Devices


Hifi Rose RS150B, system 4.3, firmware XMOS 3142

Number of Tracks in Library

Streaming only

Description of Issue

Two months ago, I began using Roon. Love it. I had great success using my 2017 MacBook Pro as a core. Songs started instantly, zero buffering, zero error messages. The laptop was connected to my network via wifi at about 250mbps down / 35mbps up.

I decided I was tired of leaving my laptop open and decided to pull the trigger on a dedicated server.

Today, I received a brand new Nucleus rev B (no ssd). I connected it to the network using CAT6 and connected it to my streamer/DAC (Hifi Rose RES150B) via USB 3.0 A to B. I updated the Nucleus software as directed by the pop-up in the Roon app. I switched from my MacBook core to the Nucleus core easily. Network speed at the Nucleus was tested at 960mbps. I use Qobuz and Tidal but listen to Qobuz primarily and expect to end my Tidal account.

I’m having a few troubles out of the gate:

Problem 1: About 1/4 of new track selections stutter at the beginning then skip to the next track. At the same time a message at the bottom pops up and says something to the effect of Qobuz is loading slowly… This never happened with the MB Pro.

Problem 2: When I send information from Nucleus to the RS150 via USB, I hear pronounced crackling in the higher frequencies during playback. It’s especially noticeable when horns are playing. When USB is bypassed and the Nucleus communicates with the RS150 on the network the crackling stops completely.

Problem 3: I use an iPhone 13 Pro with the latest software to control Roon. Now that I’m using the Nucleus, the iPhone gets very hot and burns through battery several times faster than when I used the MB Pro. The phone is about three months old and connects to the network via an Access Point that’s located about 15 feet away (Ubiquiti U6-LR). The battery went from 90% to 20% during two hours of Roon use.

Thanks, John

  1. That might be digital clipping. Go into DSP and setup Headroom Management.
  2. Why are you using USB in preference to network?
  3. Try removing and re-installing Roon on your phone. See how it behaves then.

The Qobuz loading slowly usually suggests latency. Not slow speed but a delay in responding to a request. Simplifying your network might reduce that latency. It may seem counter intuitive but put a switch between the router and your playback setup and feed the Rose and Nucleus off that.

  1. Tried adding headroom management, no change. Ordered a replacement USB cable.
  2. I’ve read on several forums that people prefer the SQ from an HDMI or USB connection to their Streamer/DAC rather than the network interaction. Dunno if science backs that up.
  3. I removed and reinstalled the app. Heat issue hasn’t changed.

Curious why I suddenly have a latency issue switching from a MB Pro core to a purpose built Roon Core. I never experienced a single buffering using the MB Pro and it was connected to the network wirelessly. Do wired and wireless connections on the same network experience latency differently? I’ll order a good switch and will see if that helps.

Is my 2017 MB Pro a more powerful machine than the Nucleus?

  1. It will be machine dependent. Some devices with poor network implementation will be better via USB. However Roon suggests a networked endpoint is preferable.

A 2017 Mac and a Nucleus will both be Intel based and be remarkably similar under the hood. A decent switch should eliminate the router from suspicion.

1 Like

@John_Wages, I don’t have a HiFi Rose device, but do have a 2019 MBPro as my Core and an AX88 router (in a mesh envrionment). I cannot speak specifically to the performance aspect of the Nucleus’ USB ports, but as @Henry_McLeod notes, Roon prefers network connections for streamers. I do not represent Roon, but the Nucleus, being built on Linux, may have a driver compatibility mismatch with your HiFi Rose streamer that was not prevalent when connected to your MBPro Core.

As your crackling sounds are eliminated when the RS150B is connected directly to the network, is this an option for you to use long-term? Does your iPhone 13 battery drain as quickly when the streamer is attached directly to the network instead of your Nucleus Core?

@Robert_F , have you experienced any “loading slowly” messages using the MBPRO as a core? Can’t say I’m not a little discouraged at this point. I’ve been searching the Hifi Rose Community and haven’t found incompatibilities like this between Nucleus and Rose products, but I sent their support a message.

As for the iPhone battery drain and heat issue, did an experiment yesterday. The streamer and nucleus were both connected to ethernet, direct to the AX88, and without USB in between. Battery drained at 5% every 10 minutes and temp shot up to 109F after holding steady at 86 while using other apps, including the streamers controller app.

Yes, I can skip the USB if it presents a problem and offers no advantage. Was hoping for the advantage though.

@John_Wages, unfortunately my MBPro has worked flawlessly as a Core for over three years now with almost daily use. I am running an ASUS AiMesh network (two nodes only) with a fiber ISP connection in a house that cannot be wired with Ethernet cable, and no major issues. And I have not had any battery issues with my 2016 iPad Pro, my new M2 iPad Pro, and my iPhone 14.

I’m wondering if your battery drain is due to a weak or congested WiFi channel or network. Is your iPhone 13 using the 2.4 or 5 GHz band, and what protocol of WiFi (n, a, ac, or ax)?

I wish I had some other information to provide you, but maybe the @support team at Roon has some information they can pull from your logs. They will be back after the long holiday weekend.

@Robert_F , glad to hear the MBPro does the job. I run my AX88 without ax mode enabled. I have 50 wireless clients on my network and some may not play well with it - although I haven’t taken time to test it yet. I run two WAPs from Ubiquiti. I have the clients divided almost evenly between the two APs and have them locked there. I’m not great at networking so there’s probably still something I can do to make mine more efficient. I run two switches - one 8 Port TrendNet GreenNet POE switch for my security cams, and one 8 Port NetGear GS108 switched. Both are unmanaged. The plan has been to swap everything to a managed Ubiquiti system, but I’ve been blowing coin on audio gear. For now, I ordered a second GS108 switch that will be dedicated to my media room.

Number one priority, approved!

I am now wondering if your APs may be overloaded, especially for those clients that can use ax and aren’t activated. It is a much more efficient protocol for both transmit/receive as well as supporting a higher number of simultaneous connections/clients. It’s not bad to have the clients tied to specific APs, but depending on what they are, their bandwidth requirements, and how they are used during different periods of the day, the APs may be stressed to capacity.

Also, are both Ubiquiti APs connected via Ethernet cable to the Netgear switch or directly to the ASUS router?

I’ll let the wireless clients auto-connect if your think that’s more efficient. And I will turn on ax to see what happens.

Wireless clients: two are WiFi 6 (iPhones), fourteen are WiFi 5, seventeen are WiFi 4, and nine are unknown (things like smart bulbs). The devices are split among three channels: 1, 36, 44. I’m using QoS with a preference for streaming. In the last 24 hours, all wireless clients have seen a total of 12GBs of usage. My heavy traffic devices are wired.

I am not aware of the devices on your network, but if you can revert to locking them to an AP if this does not work, then it seems worth it to try this.