Interesting piece on DSD and DoP

[BillK]

PS Audio’s Copper magazine has an interesting piece by Tom Gibbs discussing that DoP is not true DSD and negatively affects sound quality:

Apparently, if you’re using a delta/sigma DAC that employs ESS SABRE PRO chipsets, and are listening to anything in the DSD realm from DSD 64 through DSD 256, the output isn’t actually native DSD – it’s converted via DoP.

… [snip] …

Their chipsets all convert DSD via DoP throughout the range from DSD 64 to DSD 256, and only the very highest DSD rate is replayed as native DSD with no conversion. That’s even true of their newest flagship chip, the ESS ES9039PRO, which allows for up to DSD 1024 natively – my current DAC, the Gustard X26Pro, has a pair of ESS ES9038PRO chips with the same limitations.

I can’t begin to tell you how that information shocked me – I think I had a more intense reaction to that revelation than some of the analog guys probably did during the big Mobile Fidelity controversy last year! Dalibor had been telling me for a couple of years to avoid any devices that used DoP for DSD (and there are a lot of them), because the PCM conversion that is part of the DoP process negatively impacts the sound quality.

… [snip] …

Of course, there are tons of audio professionals and audiophiles who will tell you that bits are bits, and digital is only 1s and 0s, and that DoP has zero impact on sound quality. There couldn’t possibly be any difference between DoP and native DSD. Dalibor tells me they’ve been testing this premise for years now, and in their findings, DoP always sounds worse than native DSD.

Enjoy.

Copper Magazine: An Exciting and Inexpensive Device to Improve SACD Playback – Well, Maybe Not!

[Urbanluthier]

Re DOP, doesn’t DoP use PCM as the carrier for the native DSD data? So when the stream is unpacked the resulting DSD data should be identical to the original native DSD data? So for our purposes with dCS DACs, DoP shouldn’t make a difference, correct?

Perhaps a work around for those with DACs with the ESS chips could be – upsample to DSD 1024 with HQ player

[Anupc (Anup)]

@Urbanluthier

So when the stream is unpacked the resulting DSD data should be identical to the original native DSD data? So for our purposes with dCS DACs, DoP shouldn’t make a difference, correct?

Yes.

[meltemi (Martin)]

The DoP packing method has been (co-) developed by dCS’s Andy McHarg and is supported by a number of manufacturers. PS Audio is not one of them, ESS technologies isn’t either!
A description of release version 1.1 can be found here:
DoP open Standard | DSD-Guide.com

P.S. Use Ring DACs, not chips

[BillK]

Are you implying that may be why ESS DAC chips apparently show sonic differences between DoP and pure DSD?

I wonder if any of the “DoP harms sonic qualities” folks have tested with a dCS DAC.

[meltemi (Martin)]

Tom Gibbs, the author of the article, has not provided any justification for this:
‘DoP (DSD over PCM, which I’m not particularly jazzed by because it’s not really completely native DSD)’???

[James (James Cook)]

@meltemi

The DoP packing method has been (co-) developed by dCS’s Andy McHarg and is supported by a number of manufacturers.

Correct, and it is realistically one of the things that kept DSD as a format alive. Before DoP there was no unified way of playing DSD from a PC or Mac. One of the things to consider is that dCS were a pioneer of DSD, and in the early days of DSD – before there was ‘native’ DSD storage – dCS had to design ways of storing DSD on PCM equipment (DSD 4-wire, P3D). This was utilised in, for example, Galaxy Studios for some of the seminal DSD recordings.

The difficulty that was experienced in getting any audio at all from this “native DSD over HDMI” solution illustrates exactly why you need an agreed upon standard.

Apparently, if you’re using a delta/sigma DAC that employs ESS SABRE PRO chipsets, and are listening to anything in the DSD realm from DSD 64 through DSD 256, the output isn’t actually native DSD – it’s converted via DoP.

This part of the article really doesn’t track, as there is no way to ‘convert’ anything via DoP. The dCS implementation of DoP is done within the FPGA of a product – and is effectively a shift register with some logic to detect the markers DoP. You can easily verify that DoP isn’t PCM – simply corrupt the DoP markers (by, for example reducing the volume in non-DSD aware playback software), and you will hear the raw DSD (which sounds like noisy music at -48dB). With DoP, there is no PCM conversion - the DSD bits are preserved exactly, including timing.

Personally, the notion of “native” DSD being the holy grail is a bit counter to transmitting it via an HDMI cable. It certainly wasn’t ever done like this in the studios, and the fact that (incompatible) workarounds are needed to transmit it via HDMI hardly plays into the idea of it being “native”.

[BillK]

Yes, it’s a really strange article - that’s why I posted it - but I can also imagine that on some DACs the PCM wrapper causes an audible change.

That’s why I posted the article; this concept is a weird one, but I suppose no different than what some have heard on some DACs/streamers that sending FLAC to a DAC sounds different than uncompressing it to WAV first and sending that.

(Again, for those playing the home game, no, the bits aren’t different, but the extra processing power needed to uncompress the FLAC in real time apparently can throw noise from the processor into the system.)

However, this has been a matter of debate for some time, apparently:

Roon Community: DoP vs DSD delivered to Gryphon by macOS

[James (James Cook)]

CPUs inherently deal with ‘words’ of data better than bits, so something in the chain somewhere has to convert one to the other. Even on an SACD, the ‘bits’ are stored in a filesystem. If you’re streaming, the bits are packeted, so there will always be some work on the unpacking front.

The processing required for DoP decoding really is trivial, especially when compared to playback of FLAC for example. Decoding and playback of FLAC is a lot more work than using a shift register (though I appreciate that isn’t the comparison being made between DoP and native).

[BillK]

Right, I can’t imagine extracting DSD data from the DoP frames takes much computational power.

[BillK]

To follow up on this, in only the broadest possible sense, there is certainly “room” for things to be different here.

“Native DSD” means the DSD data stream can be sent from the receiving mechanism on to the DAC as:

D0 D1 D2 D3 D4 D5 ... D[big number here]

and is passed to whatever mechanism is used for DSD processing directly.

DoP means the data comes in and must be processed in frames:

[8 bit DSD marker]
[16 bits of DSD audio]
[8 bits of zero padding for 32-bit DoP; not present for 24-bit DoP]

Furthermore, processing must be done to make sure the DSD markers are alternately 0x05 and 0xFA to mark the PCM data stream as being DoP, the 16 bits need to be passed on, then the receiver needs to possibly skip the pad bits and go on to read/check the next DSD marker.

There is obviously a fair amount of computation that needs to happen to read and decode the market bits, make sure the marker continues to denote it’s a DoP stream, buffer the 16 bits of data and feed them to the DAC, and possibly skip the pad bits, rather than just feed the DAC a raw bitstream of native DSD bits.

If you subscribe to the “all processing can induce noise that affects audio quality” camp that believes that’s why FLAC being uncompressed on the fly sounds worse than uncompressed WAV, you certainly won’t feel good about DoP.

Now what is also clear going through the ESS docs is I’m not sure they are being interpreted correctly.

The spec sheet for the newer ESS ES9039PRO does not indicate that DoP is used for DSD rates below DSD1024, rather that it supports sample rates of “up to PCM 786 kHz & native DSD1024”.

This is opposed to the sheet for the ESS ES9038PRO that specifies “up to 768 kHz PCM, DSD256 via DoP and native DSD1024.”

In either case, the specs could be read to support the argument that all DSD below DSD1024 is DoP or they could be read as the “up to” meaning the ES9038PRO supports DoP rates up to DSD256 and native DSD up to DSD1024. Funny how a technology company can use such imprecise terms in their spec sheets. (For example, you could read that as the ES9039PRO doesn’t support DoP at all because it’s not specifically mentioned in the sample rate callout statement, which is certainly not the case.)

Regardless, you can see where those who claim DoP sounds different could possibly have a case, but as always it depends upon the implementation.

It’s quite possible that (as an example) ESS’ chips do so in a way where there are audible consequences where dCS, as a co-inventor of DoP, has mitigated them. It’s unclear.

BtW, I think it’s only fair to mention the companies that are listed as co-developers of DoP:

• Aesthetix
• Audirvana
• Benchmark Media Systems
• CEntrance
• CH-Precision
• ChannelD
• dCS
• JRiver, Inc.
• Light Harmonic
• Merging Technologies
• MSB Technology
• Mytek Digital
• Playback Designs
• Signalyst
• Sonic Solutions
• Vitus Audio
• Wavelength Audio
• XMOS

[Anupc (Anup)]

@BillK

BtW, I think it’s only fair to mention the companies that are listed as co-developers of DoP

Almost a decade prior to DoP, dCS was already transporting DSD over an isochronous packetised bus interface, i.e. Firewire/IEEE-1394, but subsequently moved to AES (PCM)-framed transport for DSD when the Vivaldi stack was developed and eventually launched in 2012 (which continues to this day in the current generation of Transport products).

dCS opened up that technology as DoP and issued the first white paper in the summer of 2011 - I’m not sure dCS wants to share that particular paper publicly anymore, so I won’t attach it here - which was well before any of those other companies even heard of the term DoP.

The subsequently “DoP Open Standard” then had contributions from multiple other parties in early 2012 on the basis of dCS’ proposal, like any open standard does, where multiple parties agree to it.

It’s funny to see companies make all sorts of claims without the context of the real history behind some of these innovations

[BillK]

The question is, did dCS do research on how different FireWire cables may have affected the sound of the transfer? Did they experiment with optical isolation when designing DoP? Or did they concentrate in both cases in making the data transfer 100% accurate and in making the protocol work as best as possible?

All I’ve stated is there are elements of the protocol that clearly provide a possible explanation for differences in sound that some say they hear on some systems, so the argument that all DoP does is packetize the bitstream into a PCM wrapper doesn’t serve to immediately dismiss the claim.

As with Ethernet, precisely no one is claiming the data isn’t being transferred in a bit perfect manner.

[Anupc (Anup)]

Well, you’ll have to ask dCS directly, but from my experience, they don’t do these things lightly, and always to the benefit of sound quality.

Besides, I rather trust dCS R&D knows what they’re doing than a random Journalism major with no technical background whatsoever posting audio gossip.

[BillK]

Wow, you really can’t reply to anyone whose opinion differs from yours without personally belittling them, can you?

[Anupc (Anup)]

Doesn’t change the fact though. Even if you ignore my commentary completely, you’re basing your entire argument on an article by a journalist with no technical background, against numerous companies with actual Engineering R&D resources. Come on.

[BillK]

Because I’ve come to trust his observations as being indicative of something I should look into auditioning for myself, something I would do even if there were definitive measurements showing it was better.

I’ve mentioned before I’ve also auditioned any number of components that had better measurements, but sounded worse in my system than other components that sounded better.

As far as “actual engineering R&D resources,” as someone who’s been in the industry themselves for 35 years, I actually would trust observations from those I trust. I can find thousands of EEs who will tell you AC power cables and filtering can’t make an audible difference; my system shows that to be inaccurate.

Philips employs thousands of engineers and spends millions annually on R&D, so I guess there’s no need for anything beyond one of their players, so I don’t even know why we’re here; CD and their players provide “pure, perfect sound forever.”