I am relatively new to Naim but I have been following this forum for a while and I have recently bought a SN2 and a second hand DAC. I am quite happy with my system but there is a question which is bugging me and that I'd like to address / answer / debate.
Naim has been developing both integrated products (the Uniti range) and single components which can be combined to build modular systems: one can buy a pure digital to analog converter (DAC), a pure integrated amplifier (SN2), a pure preamp (152 XS) and so on. There are product lines (XS, 500, Classic) that suggest meaningful combitations of these components and support building modular systems which are well balanced and devoid of redundancies.
But when it comes to servers (UnitiServe, HDX) and streamers (NDS, NDX, ND5XS), Naim does not support a modular approach. Separation of concerns is not an option anymore: you cannot, for instance, buy a pure Naim hard disk player, connect it to a dac and go.
This lack of modularity necessarily leads to bloated systems and redundancies. Why is it so? Why doesn't Naim offer streamers which are just streamers and not streamers and dacs? Why doesn't Naim offer servers which are just servers and not servers and CD players and ripping stations ?
I have been looking carefully at Naim's products and I have the impression that there is a dichotomy between the line of traditional audio devices and that of servers and streamers: the first one is open, understandable, modular. The second one is, to say the least, confusing.
I have been considering different options for building my system but I have to say that I could not find a sufficient reason to buy a Naim server or a streamer. I possibly would have bought a pure streamer (say a ND5XS without a dac) and I certainly would have bought a Naim dedicated device that just plays files from a SSD drive. And considering the number of posts in this forum concerned with the usage of Mac Minis or PCs as audio servers it appears that I am not alone.
So the question is: Naim offers excellent modular traditional products. Why doesn't Naim follow a similar approach when it comes to servers and streamers ? Why four CD players but not a single pure hard disk player ?
Posted on: 08 July 2014 by David O'Higgins
To add to Bart's reply, I decided not to use the US for downloads, to leave space for ripping CD purchases. I buy HD downloads on my PC, and then copy them to a NAS, which is visible to the US and available via Nserve. I do not buy 'red book' downloads, as the CD sounds better on my 555.
Posted on: 08 July 2014 by dave4jazz
Huge
Slightly off topic I know but given your comments above, assuming I have a DAC with multiple input options, lets say USB, S/PDIF, optical or BNC, and the source component has the equivalent output, which do you consider to be the least worse option to utilise? How would you rank them?
Dave
Posted on: 08 July 2014 by Huge
Originally Posted by dave4jazz:
Huge
Slightly off topic I know but given your comments above, assuming I have a DAC with multiple input options, lets say USB, S/PDIF, optical or BNC, assuming the source component has the equivalent output, which do you consider to be the least worse option to utilise? How would you rank them?
Dave
Hi,
Unfortunately that depends on the particular DAC and the data source, in that it will be the input where the DAC can best cope with the deficiencies of the data stream.
However...
If you have a lot of RFI or need to isolate earth loops, S/PDIF via optical can be a good choice (but the optical drivers often aren't that good, leading to jitter.
USB, if not Async, forget it. If Async, and the USB source is optimised for low latency output it could be better than S/PDIF (the native USB spec allows quite long 'wait time' type interruptions to data flow, hence the low latency comment).
S/PDIF via BNC will normally be better than S/PDIF via RCA connectors.
Sorry I can't give a definitive answer!
Posted on: 08 July 2014 by Huge
Originally Posted by Wat:
Async USB is easy to use and gives outstanding results,
...
How about a new modular DAC. It would have FPGAs, of course, no fixed forever chips. The basic DAC would have DSD/PCM digital to analogue conversion. Then there would be plugin modules that fitted in the case for
And so on ....
...
Async USB is easy to use and gives can often give outstanding results (but sometimes has big problems because of the source end)
Otherwise, interesting post...
Original thinking, exactly what this tread really needs.
Yes 
Now, if you just made a File Read module and an Ethernet streamer module available in the case, then you wouldn't have to rely on compromised data transports into the DAC, it could just read from internal memory using a common synchronous clock.
Posted on: 08 July 2014 by Huge
Originally Posted by Wat:
Yes - you could download an album/playlist in to memory In the case and play from there. The Thunderbolt, USB or Ethernet need only be active while a download is in progress And then shutdown for playback, so the mechanism became an irrelevance. Wireless would be fine in most instances. What i would like to see is TCP/IP networks eliminated from the playback as they seem to be biggest cause of problems.
...
Wat, I think we're really getting somewhere with this
How about:
Instead of a DAC as such, use a FPGA to convert DSD or PCM into Class D or (better) Class T PDM, then have a bypass-able integrator on the output.
Using class T would allow the multiplier in the FPGA to be used as a volume control without significant sound degradation at low levels (this is also where any 'room correction' would be applied).
For conventional analogue power amps, the RCA or DIN or XLR analogue output from the integrator can be used (this way it functionally behaves as a conventional DAC)
For Class D / Class T monobloc power amps or (better still) Class D / Class T active speakers, bypass the integrator and use Class D/T (low level) output directly.
Posted on: 08 July 2014 by nbpf
Originally Posted by Bart:
One point that (after a cursory reading of the handbook) was not clear to me, for example, was how I would transfer downloads from my laptop -- where I usually keep the originals zipped versions of the albums I buy and do some fine-tune retagging (e.g. adding / changing composer and conductor tags) -- to the UnitiServe when this is used as a stand-alone server. In my setup I do this by just entering a command from my laptop, no matter whether I am at home or in my office or elsewhere.
This and a few other functionalities which I consider to be mandatory to interact with a dedicated audio server seemed (to me) to be lacking (or cumbersome to realize) on the UnitiServe. I might have missed something important, of course, but this and the lack of support for an open OS were the reasons why I eventually opted for a non-Naim solution.
Yes, far too cursory a read. Ch. 9 of the owners guide describes how to copy 'external data' to the Downloads folder of the hdd UnitiServe. It's as easy to copy music to the UnitiServe as it is to copy it to my Synology nas -- drag and drop. For this use, I find the UnitiServe and nas equally easy to operate. Indeed, Finder doesn't seem to know they difference; they are both external 'drives' so to speak. When I add new music to the UnitiServe, I'm in the habit of also adding it to a shared folder on my nas, just as an extra backup (in addition to the automated backups I do).
Thanks Bart, I actually read that part of the guide but for me it was in fact a reason to turn to an alternative solution. First of all I had the impression that I was forced to copy my files to a particular (Downloads) folder. This was quite annoying: I am used to copy my files wherever I want and to name folders according to my needs. Second, I had the impression that I was forced to use some graphical drag and drop interface to simply copy files. For me, this is a no go. I'm fine if there is such an interface for those users who find it useful. But I do not want to have to rely on a graphical user interface to simply move stuff around. This is particularly true if I am working remotely. With the system I have now, I can just type something like "mirror-to-fitpc3" at the command line and press enter. This mirrors my local data to my audio server no matter whether I am at home, at work or on holiday. Done. I do not need to fiddle around with a mouse or press and hold any button. I might be completely wrong but, from what I read from the UnitiServe user guide, I gathered the impression that Naim had stripped down a proprietary OS to limit even more what users can do and was not offering any kind of support for users who want to run an open OS on the UnitiServe. As I said, I might be wrong. But it was this impression that eventually turned me away from the UnitiServe. Which of course does not mean that the UnitiServe is not a good machine. But that, most likely, it is not what I need.
Posted on: 08 July 2014 by nbpf
Originally Posted by Wat:
Yes - you could download an album/playlist in to memory In the case and play from there. The Thunderbolt, USB or Ethernet need only be active while a download is in progress And then shutdown for playback, so the mechanism became an irrelevance. Wireless would be fine in most instances. What i would like to see is TCP/IP networks eliminated from the playback as they seem to be biggest cause of problems.
I am completely ignorant at this level but I thought this was (possibly to some extent only) what the psaudio devices were doing.
Anyway, I think this is an interesting approach but it requires to carefully consider where the control process would actually live in such scenario: if the control lives on the dac (e.g., to allow stop, resume, etc. during replay) then TCP/IP traffic cannot be completely avoided, I guess.
Posted on: 08 July 2014 by Huge
Originally Posted by nbpf:
Originally Posted by Wat:
Yes - you could download an album/playlist in to memory In the case and play from there. The Thunderbolt, USB or Ethernet need only be active while a download is in progress And then shutdown for playback, so the mechanism became an irrelevance. Wireless would be fine in most instances. What i would like to see is TCP/IP networks eliminated from the playback as they seem to be biggest cause of problems.
I am completely ignorant at this level but I thought this was (possibly to some extent only) what the psaudio devices were doing.
Anyway, I think this is an interesting approach but it requires to carefully consider where the control process would actually live in such scenario: if the control lives on the dac (e.g., to allow stop, resume, etc. during replay) then TCP/IP traffic cannot be completely avoided, I guess.
The control would lie with the player. It would be given a file location - this would be the play command from the user. This could be a folder containing audio files (the files in the folder would then be played) or a playlist (which would result in all the files in the list being played) or a single audio file (would then be played).
Once an individual audio file has been loaded into local memory to be played, the normal controls (stop, resume, etc. as you say) would be available, these would be actioned by the player.
The data storage would be just that - storage; it would need no intelligence and no UPnP server.
P.S. for anyone thinking more deeply into this; gapless replay can be achieved using a ping-pong buffer arrangement.
