[Torq]

   
Another DAVE owner who has a 12 Core Mac Pro has successfully run DSD files on his DAVE.  Hi @romaz, is it DSD64, 128 or 256 with your Mac Pro?
 
I have on one occasion after much meddling with everything got the DAVE to almost finish a 3 minutes DSD256 song successfully with almost the same spec MBP as yours.  But, it paused with 20 seconds to go.
 
I pretty much gave up with the MBP and waiting for a Sonic Transporter and micrRendu to arrive to work with the DAVE.
 
For DSD files, I only listen with the Nagra HD DAC.
 
Paul

DSD64 does seem to work fine, even from the little Retina MacBook.
 
Via my Auralic Aries it also works up to DSD64.
 
So far haven't gotten my SonicOrbiter SE to play native DSD at all, despite configuring it to do so ... but will have to have another play with that, it was late and I may have missed something.

 

[Torq]

  Paul, the problem is DoP (which is not truly native DSD) as few DACs are capable of handling a DSD signal any other way.  DoP requires resampling and thus requires CPU power.  DSD64 and 128 are easier to process but DSD256 is apparently CPU intensive.  With my Mac Pro (12-core, 64GB RAM, 1TB SSD) and using Roon 1.2, I can play anything via USB to my DAVE, up to DSD256.  I can even surf the web while music is playing and I have no issues.  I have also recently tested a 6-core Mac Pro and this seems to work fine with DSD256 files.  With the older Roon version that came out in January (3-4 builds ago), even DSD 128 was stalling on my powerful Mac and so part of the problem has to be Roon.
 
Of course, if you have Windows and you use Chord's ASIO driver, you can feed your Chord Mojo or DAVE a native DSD signal (not DoP) and there are no skips or stalls because your computer is not having to resample the file at all.  
 
Because the Nagra is a DSD dac, I am not surprised the Nagra has no problems.
 
For those getting a microRendu and sonicTransporter, Jesus Rodriguez and Andrew Gillis are working on a solution to allow the microRendu to feed a Chord dac a native DSD signal (without having to resort to DoP) and so I am hoping a fix is in sight.

 
Can I ask what version of OS X you're running?
 
I don't think it's a CPU horsepower issue (that could be a factor on lower powered machines - don't see it on this level of hardware) ... it's barely ticking over there.

 

[romaz]

   
Can I ask what version of OS X you're running?
 
I don't think it's a CPU horsepower issue (that could be a factor on lower powered machines - don't see it on this level of hardware) ... it's barely ticking over there.

El Capitan, version 10.11.3.
 
You obviously have plenty of horsepower.  I've purposely not updated beyond my current version because everything is working well.

 

[Torq]

  El Capitan, version 10.11.3.
 
You obviously have plenty of horsepower.  I've purposely not updated beyond my current version because everything is working well.

Thanks!
 
I've reproduced the issue on 10.11.4 and 10.11.5 ... don't have a machine with an older build ... might have to rebuild one with a pre-El Capitan install and, if that works, upgrade until it breaks.  Will post my results if I do.

 

[paulchiu]

  Paul, the problem is DoP (which is not truly native DSD) as few DACs are capable of handling a DSD signal any other way.  DoP requires resampling and thus requires CPU power.  DSD64 and 128 are easier to process but DSD256 is apparently CPU intensive.  With my Mac Pro (12-core, 64GB RAM, 1TB SSD) and using Roon 1.2, I can play anything via USB to my DAVE, up to DSD256.  I can even surf the web while music is playing and I have no issues.  I have also recently tested a 6-core Mac Pro and this seems to work fine with DSD256 files.  With the older Roon version that came out in January (3-4 builds ago), even DSD 128 was stalling on my powerful Mac and so part of the problem has to be Roon.
 
Of course, if you have Windows and you use Chord's ASIO driver, you can feed your Chord Mojo or DAVE a native DSD signal (not DoP) and there are no skips or stalls because your computer is not having to resample the file at all.  
 
Because the Nagra is a DSD dac, I am not surprised the Nagra has no problems.
 
For those getting a microRendu and sonicTransporter, Jesus Rodriguez and Andrew Gillis are working on a solution to allow the microRendu to feed a Chord dac a native DSD signal (without having to resort to DoP) and so I am hoping a fix is in sight.

 
That part on Windows.  I need to ask you on another day Roy.
 
Off to bed.  Graduation in a few hors!

 

[harmonix]

Paul, the problem is DoP (which is not truly native DSD) as few DACs are capable of handling a DSD signal any other way.  DoP requires resampling and thus requires CPU power.  DSD64 and 128 are easier to process but DSD256 is apparently CPU intensive.  With my Mac Pro (12-core, 64GB RAM, 1TB SSD) and using Roon 1.2, I can play anything via USB to my DAVE, up to DSD256.  I can even surf the web while music is playing and I have no issues.  I have also recently tested a 6-core Mac Pro and this seems to work fine with DSD256 files.  With the older Roon version that came out in January (3-4 builds ago), even DSD 128 was stalling on my powerful Mac and so part of the problem has to be Roon.

Of course, if you have Windows and you use Chord's ASIO driver, you can feed your Chord Mojo or DAVE a native DSD signal (not DoP) and there are no skips or stalls because your computer is not having to resample the file at all.  

Because the Nagra is a DSD dac, I am not surprised the Nagra has no problems.

For those getting a microRendu and sonicTransporter, Jesus Rodriguez and Andrew Gillis are working on a solution to allow the microRendu to feed a Chord dac a native DSD signal (without having to resort to DoP) and so I am hoping a fix is in sight.

Just to he clear on the pc side there should not be any processing for a dsd signal. You can count chopping up the dsd signal into dop packets but that really doesn't strain any modern day pc. The limit on that side would be your onboard memory availability, speed of your drive if you do partial cache, and ultimately the bandwidth of your transmission bus and cable (ie usb).

The real processing for dsd signal should come on the dac side in terms of noise shaping but (I believe) double and quad rate dsd (128 and 256) should actually make noise shaping an easier burden than DSD64 as it will be pushing it way into the ultrasonic region.

As for the DAC specifically the nagra and the chord I do not believe they resample as the do DSD natively and are DSP based versus of the shelf chipsets which may convert

 

[romaz]

 
Thanks!
 
I've reproduced the issue on 10.11.4 and 10.11.5 ... don't have a machine with an older build ... might have to rebuild one with a pre-El Capitan install and, if that works, upgrade until it breaks.  Will post my results if I do.

Roon is all about ultimate SQ these days and while that's good, it comes with problems.  Here's why DSD256 playback on a Mac can be brutal using Roon:
 

 
 
If you notice, DSD256 playback is not bit perfect.  DSD256 is first converted to PCM but at a very high sampling rate of 1411kHz.  It is then downsampled to 352.8kHz before it is fed to the microRendu because no DAC can handle 1411kHz PCM.  It used to downsample to 705kHz because the DAVE is capable of up to 768kHz but I was getting all kinds of stalls.  This is when Roon decided to downsample further to 352.8kHz and that is when the drops and stalls went away for me but obviously, some systems are still having problems.  Either way, a whole lot of steps...

 

[romaz]

Just to he clear on the pc side there should not be any processing for a dsd signal. You can count chopping up the dsd signal into dop packets but that really doesn't strain any modern day pc. The limit on that side would be your onboard memory availability, speed of your drive if you do partial cache, and ultimately the bandwidth of your transmission bus and cable (ie usb).

The real processing for dsd signal should come on the dac side in terms of noise shaping but (I believe) double and quad rate dsd (128 and 256) should actually make noise shaping an easier burden than DSD64 as it will be pushing it way into the ultrasonic region.

As for the DAC specifically the nagra and the chord I do not believe they resample as the do DSD natively and are DSP based versus of the shelf chipsets which may convert

What I am talking about has nothing to do with the DAC.  It is all about what Roon does with DSD256 before it is fed to the DAC and this indeed is CPU intensive.  The reason why you have less problems with PCs is because on a Windows platform, unlike Mac or Linux, you need a driver to play high res files and so on Windows, you have to use Chord's ASIO driver.  Chord's ASIO driver has incorporated a path for the DAVE to receive a native DSD signal through Roon without DoP.  This is what you get with Roon if you use Chord's ASIO driver:
 

 
The DSD Playback Strategy option doesn't even show up on a Mac.  Even better, you will notice DSD256 remains bit-perfect.

 

[harmonix]

What I am talking about has nothing to do with the DAC.  It is all about what Roon does with DSD256 before it is fed to the DAC and this indeed is CPU intensive.  The reason why you have less problems with PCs is because on a Windows platform, unlike Mac or Linux, you need a driver to play high res files and so on Windows, you have to use Chord's ASIO driver.  Chord's ASIO driver has incorporated a path for the DAVE to receive a native DSD signal through Roon without DoP.  This is what you get with Roon if you use Chord's ASIO driver:




The DSD Playback Strategy option doesn't even show up on a Mac.  Even better, you will notice DSD256 remains bit-perfect.

What you are talking about has nothing to do with Paul Chius issues which this was the discussion thread on.

No idea on sonore/microrendu issue so you are going to have to answer your own questions which still dont help Pauls issues...

 

[romaz]

What you are talking about has nothing to do with Paul Chius issues which this was the discussion thread on.

No idea on sonore/microrendu issue so you are going to have to answer your own questions which still dont help Pauls issues...

Sorry, it looks like it is you that jumped into a conversation that had nothing to do with you. If you take note, it was Paul who brought me in and asked for my response and my response is indeed relevant to his issues because Paul has been PMing on this issue for some time.  If you take further note, it was Paul that brought up the Sonore microRendu.  Not to worry, though, I'm done here.

 

[harmonix]

Sorry, it looks like it is you that jumped into a conversation that had nothing to do with you. If you take note, it was Paul who brought me in and asked for my response and my response is indeed relevant to his issues because Paul has been PMing on this issue for some time.  If you take further note, it was Paul that brought up the Sonore microRendu.  Not to worry, though, I'm done here.

My bad then. It sounds like you sorted Paul out with rune and happily running DSD256 then
Cheers

 

[Torq]

I got hold of an Auralic Vega to test a bit more with.
 
The Vega is having no issues at all with DSD128 via DoP, where as the Mojo still exhibits drop-outs.
 
Unfortunately the Vega I got hold of doesn't have the 2.x firmware, so there's no way to test it with DSD256 (and a firmware update requires returning the unit to the manufacturer).
 
I did a bit more reading, including refreshing my memory of the USB 2.0 Audio specs and then looking at the standards for DoP 1.0 and 1.1.  And the short version there is that the PCM channel is more efficient when used for PCM data than it is for DoP data.  In other words, DoP format data fits fewer actual sample bits per frame than standard PCM (this is because additional information has to be included for DoP to identify the stream).
 
The net effect of this is that the required, sustained, USB transfer rates for DoP signaling are rather higher than for PCM of the same equivalent bit rate/depth.  When you do the math (if I've done it correctly) DSD128 over DoP 1.0 is right at, and DSD256 over DoP 1.0 is beyond, the maximum sustainable transfer speed for USB 2.0 (which is somewhat lower than the theoretical 480 Mb/s.
 
With DoP 1.1 more sample bits per frame can be transmitted and it comes in at just under the USB 2.0 transfer speed limit.  It's very borderline and wouldn't take much in terms of cable, hub, USB chipset or software to upset it.
 
Obviously using a native driver that doesn't have to deal with the transmission (not processing) overhead over putting DSD data over a PCM stream, and the required USB transmission rate falls to a point where it's within the USB 2.0 spec for sustained transmission and has enough leeway that would give you some allowance for less-than-ideal hardware/software in the chain.
 
Since Mojo, officially, only supports DoP 1.0 that pretty much ends the mystery for me.
 
The interesting question would now be whether it's actually possible to get drop-out free DSD256 with a Mojo from a Mac (the specs say "no").

 

[harmonix]

  I got hold of an Auralic Vega to test a bit more with.
 
The Vega is having no issues at all with DSD128 via DoP, where as the Mojo still exhibits drop-outs.
 
Unfortunately the Vega I got hold of doesn't have the 2.x firmware, so there's no way to test it with DSD256 (and a firmware update requires returning the unit to the manufacturer).
 
I did a bit more reading, including refreshing my memory of the USB 2.0 Audio specs and then looking at the standards for DoP 1.0 and 1.1.  And the short version there is that the PCM channel is more efficient when used for PCM data than it is for DoP data.  In other words, DoP format data fits fewer actual sample bits per frame than standard PCM (this is because additional information has to be included for DoP to identify the stream).
 
The net effect of this is that the required, sustained, USB transfer rates for DoP signaling are rather higher than for PCM of the same equivalent bit rate/depth.  When you do the math (if I've done it correctly) DSD128 over DoP 1.0 is right at, and DSD256 over DoP 1.0 is beyond, the maximum sustainable transfer speed for USB 2.0 (which is somewhat lower than the theoretical 480 Mb/s.
 
With DoP 1.1 more sample bits per frame can be transmitted and it comes in at just under the USB 2.0 transfer speed limit.  It's very borderline and wouldn't take much in terms of cable, hub, USB chipset or software to upset it.
 
Obviously using a native driver that doesn't have to deal with the transmission (not processing) overhead over putting DSD data over a PCM stream, and the required USB transmission rate falls to a point where it's within the USB 2.0 spec for sustained transmission and has enough leeway that would give you some allowance for less-than-ideal hardware/software in the chain.
 
Since Mojo, officially, only supports DoP 1.0 that pretty much ends the mystery for me.
 
The interesting question would now be whether it's actually possible to get drop-out free DSD256 with a Mojo from a Mac (the specs say "no").

When I do the math it is substantially lower than the 480mbit/sec USB 2.0 theoretical max.
Even with typical actual speeds about half of that it still should be ok.
 
DSD64 = 2.8224mhz ~ 2.822 mbit/sec raw stream. Repack into a 16 bit/176.4k PCM stream + DSD markers overhead 8bits = 24bit/176.4k PCM = 4.2336 mbit/sec
DSD128 = 5.6448mhz ~ 5.6448 mbit/sec raw .... = 24 bit/ 352.8khz PCM  (i.e. DXD equivalent) = 8.467 mbit/sec
DSD256 etc...
 
Now there are alot more things involved such as drivers, all kinds of latency issues, usb bus noise, usb cable quality etc...
but the don't think the USB 2.0 or DoP spec is the problem...

 

[Torq]

When I do the math it is substantially lower than the 480mbit/sec USB 2.0 theoretical max.
Even with typical actual speeds about half of that it still should be ok.

DSD64 = 2.8224mhz ~ 2.822 mbit/sec raw stream. Repack into a 16 bit/176.4k PCM stream + DSD markers overhead 8bits = 24bit/176.4k PCM = 4.2336 mbit/sec
DSD128 = 5.6448mhz ~ 5.6448 mbit/sec raw .... = 24 bit/ 352.8khz PCM  (i.e. DXD equivalent) = 8.467 mbit/sec
DSD256 etc...

Now there are alot more things involved such as drivers, all kinds of latency issues, usb bus noise, usb cable quality etc...
but the don't think the USB 2.0 or DoP spec is the problem...

You're only counting the bit-level data, not all the other elements of each data block You're also only accounting for a single channel (i.e. Mono). It's not just the raw PCM or bitstream data. The raw bit level data alone for 24/192 is > 9 Mb/s. Then you have a bunch of protocol overhead on that. And that's for PCM. DoP 1.0 incurs an additional 30% penalty over PCM (i.e. it transmits a third less sample data per frame).

If you were using a native driver, you could transfer much more efficiently ... but PCM has overhead and DoP adds more overhead on that. Quad rate DSD would saturate the bus if it was operating at full speed constantly. USB 2.0 rarely hits 480 Mb/s for anything more than short bursts. Sustained rates, even without switching overhead on the controllers, is much closer to half that. And that's too slow for DSD256 over DoP 1.0. It's borderline for DSD128.

Take a look at the details of the the frame definition, not just the sample data bits within it, and then account for two channel audio, and you'll see why it's a problem for DoP 1.0 and less so for 1.1.

 

[harmonix]

You're only counting the bit-level data, not all the other elements of each data block You're also only accounting for a single channel (i.e. Mono). It's not just the raw PCM or bitstream data. The raw bit level data alone for 24/192 is > 9 Mb/s. Then you have a bunch of protocol overhead on that. And that's for PCM. DoP 1.0 incurs an additional 30% penalty over PCM (i.e. it transmits a third less sample data per frame).

If you were using a native driver, you could transfer much more efficiently ... but PCM has overhead and DoP adds more overhead on that. Quad rate DSD would saturate the bus if it was operating at full speed constantly. USB 2.0 rarely hits 480 Mb/s for anything more than short bursts. Sustained rates, even without switching overhead on the controllers, is much closer to half that. And that's too slow for DSD256 over DoP 1.0. It's borderline for DSD128.

Take a look at the details of the the frame definition, not just the sample data bits within it, and then account for two channel audio, and you'll see why it's a problem for DoP 1.0 and less so for 1.1.

What is that extra "overhead" - is that outside the DoP protocol definition?  A DSD64 stream should be packaged into a 16 bit packets but an extra 8 bits is needed for the DoP protocol to wrap this into a PCM frame making 24 bits. There should be no difference in terms of data stream of a DSD64 vs. PCM 24 bit/176.4k stream?
 
http://dsd-guide.com/sites/default/files/white-papers/DoP_openStandard_1v1.pdf
 
Now I'm curious thought I understood this but it seems there is more to it.