I’ve not used Roon yet, but I am very likely to purchase a Nucleus or Nucleus plus. I’ve read threads discussing when to get a + over the standard nucleus. But what about the notion of getting a mucleus + because it will be more future proof–i.e. with a faster processor and more RAM it should be able to withstand for a longer period of time the inevitable changes that come with digital audio.
thanks for any thoughts you might have.
In my (long) experience it is rarely useful to do that because the cost of computer power drops so rapidly, as illustrated by Moore’s law.
As an extreme example, the first computer I bought for myself (as opposed to my employer’s big machine) I tried to future-proof: I bought IBM’s top of the line PC for $5,000 (in 1986, $12,000 in today’s money), it had 1 MB of RAM although the OS could use only 640k. Didn’t last long. Ha ha ha, yes we were silly in those days.
But now I’m looking at the supercomputers I have bought in recent years, which quickly become obsolete, I offer them to my sons as hand-me-downs and they decline the gift.
Of course, you don’t want to aim too low, to buy a marginal machine that can just barely manage.
My choice: I already had a powerful NUC, when the Nucleus came out I bought a regular Nucleus, not a plus. I use a convolution filter, even with DSD or 24/352 the load factor doesn’t get worse than 16 (which means I use 6 % of the power). In other zones where I don’t do room correction the load factor isn’t even shown which means the load is less than 1 %. If I would try to stream to all 7 zones simultaneously, 24/352 with convolution, I might have a problem, but that would be for a house party full of audiophiles, I don’t do that.
And our needs change: I bought a 2 TB SSD to go in the Nucleus, only needed 1 but “future-proofing”, it cost a fortune, and in the last 12 months 99 % of my 1,000 new albums are streaming.
Thank you for the replies. My thinking was that if I could avoid the next nucleus update with the i7, then i would break even and then some, i.e. the assumption would be that a + has strong functionality twice as long as a regular nucleus.
i am a bit scared that the tech in the nucleus and the + is two years old now. high end digital audio gear should be priced similarly to computers–the old stuff gets cheaper as new chips and cheaper memory are available (as is pricing for cars for that matter).
Jeff, you should really base your decision solely on the size of your library and your predicted DSP requirements. The OS on the Nucleus is very light weight and requires only low end computing power. With my base model Nucleus, I’m doing Volume Leveling, Headroom Adjustment, Parametric EQ, and Sample Rate conversion to DSD256, and my Processing speed is still a comfortable 3.3X. The base model Nucleus is really more capable than a lot of people give it credit for.
Jerry
If you don’t need the minimalist design, you could buy a PrimeMini4 for the price of a Nucleus with the power of a Nucleus +. That’s what I did.
Out of curiosity just priced a PrimeMini 4 with i7, 16GB SDRAM, 250GB m.2 SSD, 2TB SATA SSD: $1659, which sits between Nucleus and Nucleus+ in price. If I didn’t have already a reasonable fanless NUC I got from QuietPC in the UK in 2018, I’d be tempted. But no self-managed NUC setup is going to be as lean-for-Roon as the Nucleus(+) because Roon shrinks Linux down to the minimum needed for Roon, unlike the almost-out-of-the-box Ubuntu Server I run on my NUC (Roon ROCK won’t install on my current NUC for some weird BIOS reason I couldn’t be bothered to waste much time on).
If you really want to be future proof just store and back up your music files on hard drives 2x.
I live in Germany, so the delivery cost is low (the PrimeMini is assembled in Switzerland).
I installed ROCK without any problem. The NUC the PrimeMini uses is in the list of supported NUCs.
The NUC options are interesting, but I prefer the turnkey solution. maybe i should get adventerous, but i’m not an IT professional. Perhaps one doesn’t need to be. But to illustrate my level of understanding, i still can’t figure out that if I have a roon nucleus and a streamer as a roon endpoint, which device does the streaming? i’ll have to start another thread for that one.
A Nucleus is a good option, but I wonder if you’re putting the cart before the horse. Try Roon first. Most people really like Roon, but Roon philosophy can be a deal breaker for some. For instance, if you want folder browsing it’s never going to happen. If you try it on a PC and like it, then consider a Nucleus but base your buying decision on the size of your library and your DSP requirements. I’ve got a first gen Nucleus and it works perfectly. I feel no need to upgrade to anything more powerful with my 3,200 album library.
The Nucleus (or other machine running Roon Core) serves as the command center for Roon. It stores a database that describes your music library and choices, it connects via the Internet to streaming services, it accesses local stored music (either on a local disk or on a server on your home network), it does any requested signal processing, and it sends digital audio to Roon endpoints over your home network. Roon control points (typically convenient devices like phones, tablets, laptops) also on your home network, allow you to control what the Core does and what endpoints it plays to.
The Nucleus (and other core machines) can also connect directly to a DAC or digital receiver with USB audio, without the need for an endpoint. But with separate endpoints you can have multiple music systems controlled by the same Roon core (I have 3, for instance) and endpoints are built into some audio systems directly, without need for a separate endpoint box.
If the nucleus connects to TIDAL, downloads the music file and does (potentially) DSP, then why can’t I send the resulting data straight to a DAC via hardwired ethernet (I guess not Wi-Fi as the file is too big if DSP is used)? I don’t understand why a streamer, i.e. a box that connects to TIDAL and sends a clocked stream to a DAC, is needed if one has the nucleus. what does a network streamer do that the nucleus doesn’t, other than possibly the DAC?
I should start a new thread I suppose…
Thank you for your responses!
In the case of Roon, it’s the Roon Core server which connects to Tidal, downloads and buffers the Tidal streams, does whatever DSP magic you have configured, and directs the resulting digital bit stream to output in on whatever endpoint you have configured.
The Roon Core server can be Nucleus, or it can be a NUC configured with ROCK, or a Linux, Windows or Mac box with the Roon software installed.
The endpoint can be any of the available digital outputs of the Core server - USB, HDMI, S/PDIF… Or it can be a digital output of another device connected to the same network as your Roon Core server - preferably connected via Ethernet cable, but WiFi works well in some environments. This other device needs to have a software component which speaks ‘RAAT’, which is the protocol Roon uses to send the digital bit streams to the output. The software may be built-in as in Roon-Ready certified streaming products, or it may be the Roon Bridge software component you can download from the Roon web site and install on a computing device on your network.
The Roon Core server discovers and presents in its configuration interface any Roon Bridge software components present in devices on your network, be it Roon-ready devices or computing devices with Roon Bridge installed.
So, in my understanding it’s always the Roon Core server which ‘prepares’ the digital bit stream and sends it to any output device discovered and configured on the network.
Sure, a “streamer” (a network endpoint with an Ethernet jack on one side and a USB or SPDIF jack on the other) is not necessary.
Two reasons for using one:
Personally, I use several network endpoints because of distance, but I have not heard any difference so for short distances I’m using USB directly.
However, wrt Tidal or other cloud services: you should not think of them downloading a file, they do streaming which means the music is flowing down but there is never a complete file in your house. This is for both technical and legal/contractual/licensing reasons.
The “file” size does not change unless you’re upsampling (adds bits) but no amount of upsampling will grow the amount of data that needs to be moved beyond the capability of any current Wifi network.
You can think of Tidal serving files but RAAT and other “streaming” protocols are not serving files. At least not in the way you’re thinking of a file. So, for this exercise don’t think of it as a file but think of it as a continuous stream of bits that are time synchronized to arrive at the renderer which is then responsible for “rendering” those bits into one of the digital output formats like S/PDIF or USB Audio 2.0. Each of these is a different specification on how to clock (feed the bits at very specific time intervals) and transfer the bits across the digital connection. The closer you get to the DAC the more precision is required within the clocks to stay accurate and that’s why you hear of things like “reclockers” and different USB implementations to keep the timing stable. The DAC is then responsible for converting the bits into an electrical signal on the output. A change between two bits becomes a change in voltage on the output.
In my set-up: Core over ethernet -> Renderer to USB -> DAC balanced cables -> pre-amp
That renderer has a network buffer for unpacking RAAT and reading the bits which represent the audio. It then precisely sends the bits over USB Audio 2.0 for the DAC to convert to a voltage on the balanced output.
In what you describe, the renderer and DAC would be combined on the same device and there are plenty of devices that do this. But, the process is no different. Usually the internal connection between the renderer part and the DAC on these devices uses something called I2S (pronounced eye-two-ess).
So, why not just use a streamer? A streamer would combine even more parts of the puzzle together. Most people believe that as you break-apart all of these individual steps in the chain they can be optimized with better power supplies, isolation, etc. and that allows for better sound quality. This is why Roon recommends attaching endpoints across the network instead of direct connect. It adds a buffering and isolation layer between the renderer and the core. But, you cannot skip a step. Tidal “file” must be unpacked to get to the PCM data stream, that must be fed accurately and in-time to a DAC, the DAC must be accurate in representing that as voltage changes on its output.
Anyway, hope that helps.
Thank you Anders. If the nucleus (or device running Roon core) is connected to a streamer, but the streamer is streaming the file from TIDAL (say), then how does one use the core for DSP? It would seem if a streamer that is a roon endpoint is streaming the file, then the streamer also has to do the DSP.
is that correct?
Not quite so. If a streamer is connected as Roon endpoint, it effectually functions as a bridge device… It receives the RAAT bit stream on one interface (Ethernet) and directs it to an output interface (say USB).
If the streamer has an inbuilt DAC, then it receives the RAAT bit stream and passes it on to its DAC. The output in this case is analogue via RCA or balanced outputs.
A streamer device in the Roon ecosystem doesn’t really stream… But streamer devices outside the Roon ecosystem can stream directly from Tidal or other providers, or from local files on a drive attached to it. In Roon it’s the core only which connects to Tidal or other providers, and it’s the core only which does DSP processing and preparing of the RAAT bit stream.
the quoted text helps a lot! that is what i was thinking–the streamer in a Roon setup doesn’t stream or do DSP. I’m still confused why i can’t send the data from the nucleus, which has been possibly DSP’ed, directly to a DAC over wi-fi or ethernet, i.e. why would I need a streamer that can stream as an endpoint? something to do with clocking? someone above has probably answered this and i didn’t understand correctly.
anyway, I very much appreciate the detailed, clear and thoughtful responses!
As @Andreas_Philipp1 says, in the Roon architecture the Core always brings in the music (from disk, from a NAS, from cloud services), translates it as necessary, processes it as desired (e.g. room correction, volume alignment), and then sends it to the endpoint/DAC. This guarantees that the same capabilities are available on all endpoints, in all rooms. E.g. DSP room correction works the same for Tidal and your own CDs. Don’t have to worry about whether a DAC has licensed the format that some streaming service or download service sends, such as DSD or 24/352 FLAC or ALAC or AIFF or whatever.
This sometimes surprises people, there are some DAC endpoints that contain disk, but even then, if you want to play music from that disk Roon has to bring it back, translate and process it, and then send it out again, maybe even to the same DAC.
