Thanks, Amir. Good stuff! I have read quickly, but need to re-read at least once more.
In the meanwhile, a few questions:
- What if the network player or bridge you are using doesn't provide USB. Are you stuck with "inferior sound", or should a well-designed DAC be able to recover the clock and capably deal with information coming from the SPDIF interface and match performance of properly implemented USB? How can you tell if the physical hardware implementation in the network player or bridge is well designed or is drek? For example, despite the issues, when this reviewer got everything working, he liked things much better than his Mac.
http://www.audiostream.com/content/totaldac-d1-server
Networked systems act and work exactly like USB async. The problem they bring with them is lots of system activity in the DAC itself. Lots and lots of code is now running inside the DAC's CPU subsystem and if not impeccably isolated, it can bleed into the DAC much like we see in cheap computer motherboard sound. Indeed it says the same thing in that article:
"The totaldac d1-server is based on an 800MHz ARM based Cubox minicomputer running RTLinux (Real-Time Linux) and the MPD music player daemon."
If it is one time you don't want to brag about having a computer inside something, it is a DAC
. It goes to say the "right" thing:
"There's an integrated "digital reclocker" which accounts for a large chunk of the d1-server's price—the d1-digital reclocker is available as a stand alone device from totaldac for about $4,900 while you can pick up a Cubox 2" cube computer for around $100. "
A "reclocker" is mandatory in a network device as there is no sample accurate clock available in general computer networking to drive the DAC. The DAC will use its own clock and request data to arrive asynchronously from the network source. In that sense, there is nothing to reclock. There is only one clock and it is the master driving the DAC.
I don't know what the heck this means though:
"In order to use the reclocker, you have to run a USB cable on the back of the d1-server from the integrated minicomputer's USB Type-A output (the one on the bottom) to the USB Type-B input. This setup also allows you to use the reclocker with an external source. The reclocker uses the same asynchronous fifo memory as the d1-dual DAC and according to totaldac, "...it also has an internal clock which strongly attenuates the jitter of any digital source"."
Minicomputer??? Minicomputers went out of the business in 1980s. Embedded microcomputer is what is inside the DAC. Not sure what they are saying is being done with USB inside of a DAC driven by sources other than USB???
But answering your question, the only way to evaluate any such claims is with measurements. Words about how they clock this and that are worthless. If we are discussing engineering topics then there better be engineering proof points. Can't say reclock this and that and for the proof say how "musical" the DAC sounds.
- And is the UPnP serve software on the NAS all the same? For example, some swear by MinimServe / Synology combination but others poo-poo it. Is it wrong to expect that some software will buffer better or convert the file to a format that can be processed easier by the DAC, reducing computing power and producing better sound? For example, doesn't the processing required to un-compress the data from FLAC increase the computational load, which could raises the power supply noise floor, which detracts from the sound quality?
The biggest and only issue with UPnP servers is reliability. They cannot change the sound quality. They are at the end of a wet noodle. They can do what they want and it won't move the other end. They are sitting on a different computer, linked asynchronously to a client DAC. They simply have no ability to change fidelity.
UPnP does not support FLAC which means that the server will decompress that into PCM and send that over the wire. Yes, that increases the server's CPU but that CPU is not sitting inside the networked DAC so it cannot influence its performance. If you are getting reliable stream of music, then the server has done its job and replacing one for another will not make a difference.
Simply, put, couldn't some UPnP software just work better than other software and provide better synergy or better sound?
The only synergy is from reliability point of view. UPnP is one of those "standards" which was never tested very well. To the extent there is a server and networked client that are designed to work together, you will get more reliable operation potentially. But that is it. Changing one for the other should only be done for reliability sake, not sound fidelity.
Now, you can build a really, really bad networked player where everything from its CPU does bleeds into the DAC. In that case, yes, changing any network activity will cause its DAC to run differently. Say one server that is decompression FLAC produces pauses every 1 millisecond when it is decompressing the file and then it bursts it out on the network. That 1 KHz cadence can bleed into the DAC. But this is not a problem with the server but absolutely horrible networked DAC implementation. The server is compliant with what it is supposed to do: produce data. Its job is not to produce analog sound. It is the job of the networked DAC to produce high fidelity audio samples from what is by definition an noisy asynchronous digital audio feed. Again, measurements will tell us the competence of such designs/designers.
At high level, we must engineer products well. Only then we can (maybe
) dabble into secondary considerations of "how does it sound." If a networked DAC's objective measurements show it to produce different data when you change the UPnP server, you don't get to second argument of "but it sounds good to my ear." The thing is broken
. That you think it produces good sound is neither here, nor there in my book.
