Ok, that makes sense - because who would buy a new NDX2 and just use it as a transport within a Roon environment? 
Many… the NDX2 is a fantastic choice for use as a transport… the DAC inbuilt is ok, but I consider more a backup/resilience option, but as a transport first class… and of course you are using most of the streamer by function when in transport mode… with a relatively smaller part dedicated to the analogue out. (Although by surface area it takes more space as the components are larger)
The architecture white paper illustrates this quite nicely.
I really think many under appreciate the significance and importance of the transport, Naim have a winner here… to be fair they learned a lot from the relative limitations of the legacy streamers and the earlier transports and clocking techniques.
2 Likes
According to Chord, your Hugo re-clocks – so it doesn’t really care about Naim’s clock. Admittedly, there is more to a transport than just the clock. Nonetheless, that makes me really struggle to understand all the fuzz about clocking when using Chord DACs with their FPGA chip.
Not really, just about all DACs reclock these days, they have for years.
It’s the transport clock jitter couples into the noise floor of the DAC through the digital receiver modulating the ground plane through a distribution of sidebands, not unlike an FM modulator.
Therefore for optimum performance the DAC, and the Hugo is no exception as I can confirm, needs a stable as clock as possible to minimise the sidebands.
I think you are thinking of the old fashioned way in the 90s where it was not uncommon for the actual DAC clock to be derived from the SPDIF transport clock … I know it feels hard to believe now, but that actually used to happen, back in the days when suitable precision clocks were rather expensive.
1 Like
Hmmm – when I asked Chord about SOTM streamers (specifically, the 200 and 200 Ultra), they said there was little point in spending any extra monies on the 200 Ultra, as the Ultra’s main advance appears to be the better block. I was advised that the “Chord FPGA system completely ignores the clocking on the input signal and uses its own so the key selling point of the Ultra is negated”. Shouldn’t the same apply when using Naim streamers…
It doesn’t from a modulation point of view… I think you are getting two things mixed up… perhaps you need to think more about coupling and system theory … and I mused personally with Rob Watts on this… and he could understand the point, but he did say although he could hear he couldn’t measure any modulation in the ground plane on DAVE with the tools he was using… but without giving too much away he implied there were still things he was discovering.
1 Like
Isn’t the exception here when the Hugo is used through its USB connection, where it re-clocks in the coming.
Again you are getting this mixed up… this is about noise coupling… think of a tiny FM transmitter… this is not about reclocking. You could reclock a 100 times and would make no difference.
This is about ground plane and/or electromagnetic field modulation from the receiving interface circuitry… this is not dissimilar to the noise from Ethernet interfaces… again there are good engineering summary papers on this.
USB is no different from SPDIF other than USB (not v3) uses unbalanced flow control signalling which creates little EM pulses… not ideal.
1 Like
Thanks Simon. its pretty confusing. thanks for the explaination.
1 Like
Glad I could try and explain
I think some people get fixated with sample clock jitter with DACs which is a completely separate matter, and now largely moot with DACs as just about every DAC out there uses its own clock rather than trying to derive a clock from a transport clock as was done in the olden days. It is not even a nice looking multiplication to get from one to the other… (SPDIF is a set of structured frames containing blocks of sample data…it’s NOT a steady even flow of sample data)
1 Like
I am not mixing up anything – just repeat what I was told (in writing and in fairly plain English) by Chord, and that doesn’t seem to align with technical understanding…
Ok in the end just trust your ears… and do what ever works for you.
But I think you are mixed up… one is FM noise coupling and the other is sample DAC jitter and reclocking, two very different things.
Reality can’t always be explained in nice easy layman’s terms without often significant simplification or omission.
I don’t know who you conversed with at Chord, but all I know is that Mr Watts and I have discussed this at a loose engineering level one to one and he certainly gets it, well he would wouldn’t he… in fact because of that he told me about one of his mitigations of this, the mscaler which he, or more accurately Chord, was just about to launch… here you have physical system decoupling between the device ground planes and a degree of EM isolation. He was excited about other aspects of the mscaler as well.
1 Like
Simon, so are you saying SPDIF is not a good way to connect the streamer to the DAC? I use the BNC out of my NDS to connect to my TT2, and it sounds great to me. I also thought this is how you connect your Ndx2 to your Hugo 1 ?. I am picking up my Mscaler this weekend, and will use the same connection method as I currently do with the TT2.
It is a very good way in my opinion… it’s an efficient framing protocol over a 75 ohm unbalanced transmission line not requiring flow control, and it is designed exactly what it is used for.
However it is a framing protocol of chunks of stereo or surround sound media data within an overall framing structure and header structure … this allows flexibility. But it is not a solid flow of sample data… it’s packets of sample data, kind of loosely like UDP network datagrams.
The clock rate of the framing protocol is not the same as the sample clock rate… as these two operate at different rates due to the framing construct and format, headers and overheads compared to the sample data.
Ok thanks Simon, I understood the first nine words.
3 Likes
If you replay a music file with a MPD client like ncmpcpp, you can actually see the current bitrate of the stream. In the enclosed screenshot, this is the number in the bottom right corner, 1232. For this particular track, the bitrate of the stream typically oscillates between about 1100 and about 1400 kbps during replay. The track is a 24bits / 48kHz file. Thus, the sample bitrate is 24 * 48 = 1152 kbps. There is nothing really surprising going on here: as Simon has explained, the framing protocol entails some overhead and thus the observed bit rate of the stream is, in average, a bit higher than the fixed sample rate that is just the product of the length of a sample (24 bits, in this case) and of the number of sample per seconds (48k, in this case).
1 Like
Nbpf, thanks… yes the effective clock of the framing protocol bit stream is quite a bit different from the sample rate of the data… SPDIF is a series of subframes and frames within repeating blocks… these frames can be grouped into stereo groupings or multichannel groupings…
With SPDIF every sample is sent as a 32 bit sub frame, when sending stereo, every frame contains two subframes, and a block contains 192 frames. With each block 384 bits of channel status and sub code info is included (of which 15 bits are used as a bit string)… so you can see the transport clock is quite a bit higher than the embedded sample media data rate.
1 Like
I think many of us here are not very computer savvy, so a lot of what Simon and a few other posters say goes way over our heads. No offence to anyone, but I just need a simple - BNC, USB, or optical is the better choice of input.
The screenshot was meant to illustrate the difference between the bitrate of a music file (for a X bits / Y kHz file, the product of X and Y) and the bitrate of a stream that encodes that file. The first one is a feature of a static object, the music file. The second one is a feature of a process. As Simon explained and as you can see from the screenshot, these bitrates can be quite different. As mentioned, the bitrate of a stram typically varies in time as the stream is replayed.
These different notions of bitrate have actually little to do with computers, they are just properties of the things we talk about: music files and replay streams.
What is your question precisely? You want to compare streaming via USB, electrical SPDIF via BNC and optical SPDIF via Toslink for which device? What is “better” depends on the interfaces of device that provides the stream and of the device that consumes that stream. What are these devices in your specific case?
Not really computer speak, but possibly data encoding speak… but the botttom line and the point I was trying to convey underneath the covers SPDIF is a fair bit more than just sample data… it’s a flexible transport protocol with its own management data … it’s not merely a clocked stream of sample data.
1 Like