Hello,
The Aurender N20 connected to Rossini thru USB input doesn’t recognize Rossini to accept native DSD. I re-read the specification and only Ethernet input supports native DSD.
Does this affect playback of DSD files from Aurender library.
Thanks,
Vivek Baghel
It’s perfectly fine. It doesn’t affect playback of DSD files from your Aurender.
https://ask.aurender.com/hc/en-us
For DSD playback, if the DAC supports the industry standard DoP protocol, then it will be compatible with Aurender’s DSD output. DoP is a lossless, unadulterated transmission of DSD from source to DAC. It is NOT to be confused with DSD-to-PCM transcoding, which is usually less desirable from an audio performance perspective.
Thank You Anupc. I was just surprised!!
I didn’t know the Rossini accepted native DSD at all. I will check the manual. Thx.
PS: I can’t find any reference to native DSD streaming over the network interface. Perhaps you mean using Mosaic to play a DSD file (either over UPnP or USB2)? This of course would not involve DoP.
DoP is a dSC invented protocol, so understandably DoP is the preferred method. While I was searching for the transport, the primary objective was the SACD playback and whether non-dCS transport can send DSD data back to the DAC. Few transports do support DoP, but I had to settle for dCS transport because of RAW DSD. I thought RAW (encrypted) DSD means meant that dCS dual AES should accept native DSD, but dual AES accepts double rate DoP. Here’s the digital input description from dCS.
Ethernet network port on RJ45 connector, accepts 24-bit 44.1 – 384kS/s PCM, DSD/64 & DSD128 in DFF/DSF format;
Couple of things:
1- The Ethernet input:
I think, related to UPnP or USB2 (ie files in a USB stick) playback. I don’t think something like Roon can send native DSD to the dCS network card, but in principle should not matter as DoP is the same data, just packaged as PCM.
2- non-dCS transport SACD playback:
The only way to do this that I am aware of is via a small box that converts DSD data sent over HDMI to DoP PCM data. You need a suitable CD/SACD/DVD player (eg Oppo) and a suitable $100 box from eBay that takes the HDMI signal and outputs SPDIF over coax with the DSD data packaged as DoP. I have this box and an Oppo BDP-93 and it works fine.
However, I don’t use this method. Instead, I have ripped all my SACDs with a Sony BDP-S5100 and the suitable software to DSD files, and I can play those as DSD data either via Roon or Mosaic - the latter from either a USB stick or served over UPnP via Minimserver.
With the exception of the SDIF2 interface on the dCS Vivaldi, all other dCS DAC interfaces - AES/SPDIF, USB, and Ethernet - only accept DoP framed DSD, not native-DSD (“markerless”). Yes, that includes the dCS Ethernet interface, it does not support native-DSD.
This can be validated with JRiver Media Centre which supports both DoP framed and native-DSD over Ethernet - when “Bitstream DSD” (DoPE) is disabled, DSD streaming won’t work with dCS systems. It needs to be enabled for it work. All other dCS supported servers; Roon, Melco, MinimServer, Asset, etc., only stream DSD framed with DoP markers.
I believe the underlying reason for this is that the dCS Control board FPGA where all digital signal processing is done requires all incoming data to be PCM framed. If the DSD marker is found within the data, the payload is then processed as DSD, differently from PCM. This is the case for all incoming data, including from dCS’ own transport where DSD is also PCM framed over the Dual-AES interfaces.
Thank you Anup and Miguel for the insights. I am using roon on the computer and play DSF 64 files from the computer. Probably I didn’t paid any attention to roon settings.
About SACD, I did burned few SACD’s using Oppo. I has also read about HDMI to SPDIF interfaces, but have no personal experience.
I’m not sure how much I’d trust the Chinese boxes, those I know who have an Oppo with SACD capability use something like this:
The problem is, it does not have a word clock input, so when I demoed one the data stream would not lock properly with a dCS clock, causing constant dropouts.
The answer is to set clock mode to A)udio Mode, but at a quite noticeable degradation in sound quality.
(The sound quality was noticeably better in W mode in between dropouts than in A mode without any dropouts.)
SPDIF is designed such that the source is the clock. If you set your DAC to use a clock that is not slaved to the source clock (which is recovered from the audio signal itself) then there is never a guarantee this will work.
dCS gets around this by clocking every component with a master external clock. But this converter box, and most every other non-dCS component, does not have a clock input that would work with a dCS clock.
So if you ever use a clock mode other than A you are always asking for trouble with any SPDIF input that is not itself clocked with the same clock. There’s a buffer in my Rossini that would in principle buffer the SPDIF signal as it comes in and reclock it, but depending on how different the source and dCS clocks are, that buffer can underrun or overrun, giving you a glitch or break. The only way to play without glitches is to slave to the source clock, ie mode A.
One more detail on “clock recovery from the audio signal itself”: The SPDIF spec is such that there is a transition at every single clock cycle. O’s and 1’s are signaled by whether there is a transition in between or not. I say this because someone might say “What if it is all 0’s for a while, wouldn’t that allow for slippage?” No, that is never the case. However, people report that I2S is better than pure SPDIF. I2S uses a separate clock line for the clock. I don’t know why it would be better except for the fact that the clock sync is always going “up” vs “up or down” in pure SPDIF. In the SPDIF case you could have a transition detection that is slightly off on up vs down. I don’t know.
Correct.
What I was trying to say is you can hear in the brief amount of signal that is reproduced in “W” mode before the DAC loses sync because of clock mismatch, it sounds better than it does in “A” mode, which is what dCS themselves say in the manual.
Sadly, the D.BOB does not have a word clock input.
What’s a bit strange is that clocking involves a fair amount of luck sometimes; my DISH Hopper 3 satellite receiver and a Sangaen FM Tuner both work perfectly in “W₂” mode, go figure.
Understood. What is probably happening is the clocks of the devices that are working “properly” in W mode are running “closer” in frequency to the dCS clock, thereby not experiencing an over/under run of the buffer in the time you’re playing (in all likelihood, if you played long enough you might experience a glitch).
As you probably know, the dCS clock is likely to sound better than the recovered clock because the whole point of a clock is to have very low phase noise (ie the frequency stays very stable and does not slowly wonder around). The exact clock speed, given those are relatively precise even with the cheapest of designs, is not important.