Topic: ADI-2 Pro Native DSD playback

Apologies if the subject has been explained/clarified before.

My understanding is that the RME ADI-2 Pro digital inputs can only playback DSD type files fed into them in the DOP format and, accordingly, native DSD playback is not possible (a white noise type of signal is all is heard). Am I correct or is there an angle that allows the playback of DSD files in native format, avoiding DOP? This is strictly a technical capability question not about if it makes any difference or not. It also pertains to using as a source a streamer (not a computer) that can send out DSD type files in either DOP or native format.

Thanks.............................dr.larkos

2

Re: ADI-2 Pro Native DSD playback

I am not aware of transferring DSD over SPDIF in a different way than DoP. Do you have a link to a description of what you call 'native' (here: use 24 bits instead of 16 to map the DSD signal into PCM)? Maybe you confuse this with 'native' via USB (uses 32 bits to map, and needs a special Alternate Setting in the CC firmware. The latter we don't support).

Sending DSD data without repacking requires an SDIF-3 port (BNC).

The word 'native' in regard to DSD has been completely screwed over the last years...

Regards
Matthias Carstens
RME

Re: ADI-2 Pro Native DSD playback

Thanks, Matthias. When I said "My understanding is that the RME ADI-2 Pro's "digital inputs can only playback DSD type files fed into them in the DOP format," I meant precisely that, all digital inputs: SPDIF (coax & optical) and USB (not just SPDIF). I knew with certainty that  DOP is the only way to play DSD files through SPDIF inputs, but I was not so sure whether the ADI-2 Pro’s USB input could somehow do “native DSD”--the reason for my posting...So, according to your response, it is possible to do “native DSD” through a USB input (by using 32 bits to map, with a special Alternate Setting in the CC firmware), however, the ADI-2 Pro does not support that. But, is this the case for the time being or not possible at all?

Thank you again............................dr.larkos

4

Re: ADI-2 Pro Native DSD playback

It's not possible right now, and - most important - not needed at all. This scheme was introduced to be able to use DSD256 at only 384 kHz sample rate (via USB). Fortunately the ADI can use 768 kHz which gives DSD256 even with DoP-based transmission.

Another 'native' thing is ASIO native DSD transmission.

BTW, for me USB is not a digital 'input' as it transmits data in two ways.

Regards
Matthias Carstens
RME

Re: ADI-2 Pro Native DSD playback

Got it, Matthias, thank you. As I said in my initial post, my question was about technical capability or feasibility, not to debate the merit of the matter; however, I am very glad you also addressed the latter in your clear, no-nonsense fashion.

Now, a question (not to argue, just for a little fun with semantics): Couldn't we consider and call a two-way door an "entrance", or would it be incorrect because that door is also an "exit"? wink

Looking forward to that promised firmware update.

Thanks again and all the best...................dr.larkos

Re: ADI-2 Pro Native DSD playback

MC wrote:

It's not possible right now, and - most important - not needed at all.

Hi MC. I want to discuss this issue further. I'm not a fan of DSD. But having `native` (means unpacked, or not done via dop) DSD supported in alt setting is beneficial in DSD playback.

Why? Because in most players, seeking to a different position in a track will usually go through a restart signal (stop, empty the buffer, fill the buffer with new data, start). This usually goes well in PCM or `native` DSD, and there's no hiccups in the playback.

However, in DOP's case, things are different, because the device assume the incoming signal is PCM by default, so the detection algorithm has to be rerun to find the DoP Marker (0X05/0xfa) for quite a few samples until finally being confident that the new signal is a DoP one.

That's the reason that in almost all players, a hiccups/noise will be heard on RME ADI-2 Pro devices when seeking to a different position in a dsd track. This is because the playing mode is switching to PCM and back to DSD. If usb alt setting dedicated for DSD is supported, and the dsd data can be sent directly, no DOP detection will be needed, and the hiccups/noise can be avoided.

Page 43 of the ADI-2 Pro manual (19.3 DSD Playback) said this is an inherent issue of DSD playback, which is not true. DACs with proper `native` implementation are noise free during seeking or track changing (as long as they are of the same sample rate).

By the way, I notice a strange behavior with the latest firmware.  in page 44 v2.3 of the user manual (19.5 DSD Level Meter), AES and SPDIF shows -24dbfs while playing DSD. I notice the same expected behavior when playing DSD64. However, When switched to playing DSD128 or DSD256, it's the AN input that shows the volume meter, rather than AES and SPDIF output. Is this a bug?


As new forum member (and new RME user), I want to thank you wholeheartedly for creating this wonderful product. This is truly the most amazing audio interface I've ever used.

7

Re: ADI-2 Pro Native DSD playback

I fear your theory is wrong. The hickup is unavoidable as the new data can neither be faded in nor makes sense in terms of a continuing data stream. If you have a DAC where you don't hear a 'hickup' then it is muting the analog signal. Record the signal while doing a playback and check its waveform...

The time to recognize DoP is one sample, no waiting at all. Additionally a player that stops sending DSD during seek operation is flawed, no matter if DSD 'Direct' is active or not. For example with JRiver I can jump to any position within a track back and forth and DSD mode will never be lost  = no hickup.

I checked the meters and they work as expected. You're sure you don't have an analog loopback there? Or is that the (expected) constant noise of high sample rate AD conversion?

Thanks for the kind words. Next firmware update is ready and will amaze you again wink

Regards
Matthias Carstens
RME

8 (edited by ning 2019-06-09 03:16:44)

Re: ADI-2 Pro Native DSD playback

For the seeking issue. You're absolutely correct! I did a few tests on various software and found JRiver and HQPlayer are correctly implemented, whereas Foobar2000 and MPD are doing it wrong. On ADI-2 Pro's state overview screen,  When seeking using the former players, the DSD status is never changed.  However when seeking using the latter players, the DSD status quickly changes back and forth once for every seek operation. I suspect the latter players incorrectly handle DoP stream seeking and make the DoP marker bits pattern locally noncontinuous during seeking. I'll see how to fix the player code. 

(Update: the above statement is not technically accurrate. see my new reply in the next post.)

You're also right that the volume meter shows high frequency AD conversion noise when higher bit rate DSD is being played. AES and SPDIF also doesn't support higher bit rates so no volume will be shown. I previously was confused to see the right volumes bars disappeared and the left volume bars appeared when switched from DSD64 to DSD256, now I realize the reason behind that. Very educating, Thank you so much!

Wow, woke up in the morning and saw a new firmware update! That's awesome! Thanks so much. can't wait to try it:)

Re: ADI-2 Pro Native DSD playback

Euphony OS RME ADI-2 DAC usb
Native DSD playback not working
only DoP
why is that?
can i fix it?

Re: ADI-2 Pro Native DSD playback

CompanyZ wrote:

Euphony OS RME ADI-2 DAC usb
Native DSD playback not working
only DoP
why is that?
can i fix it?

Adi will only play DOP.
It cannot play native.

Your not missing anything  dsd64=176. 128=352khz and so on.

Re: ADI-2 Pro Native DSD playback

Intel NUC Roon Rock+RME ADI-2 DAC usb
Execution possible Native DSD?

Re: ADI-2 Pro Native DSD playback

As explained above, only DoP is supported. DSD `Native` (transfering DSD via USB alt setting 3) is not supported.
As long as your media player's seek function is working click-free, there's no technical benefit to transfer it natively through the USB.