INTERACT FORUM
More => Old Versions => JRiver Media Center 30 for Mac => Topic started by: The Computer Audiophile on February 15, 2023, 08:47:30 am
-
Hi Guys, I'm troubleshooting an issue with DSD playback on my Mac and have a question about what the display is telling me. In the attached screenshot, the output says DoP DSD64 (1x) 1bit 2ch using Core Audio bit streaming.
Does this mean the audio is being sent at 24/176.4 because it's DoP, or something else?
I understand how the DSD encapsulation works in the PCM container, but I'm having a strange issue that seems like 176.4 isn't being sent to the DAC. Thanks for any help you can provide.
-
Yes, from the audio info screenshot there it's bitstreaming using DSD64 using DoP via CoreAudio. As you probably know DoP is the only way DSD can be played back in macOS as there's no native DSD playback support so at least that's what is to be expected from the output from MC. What's the DAC receiving on its end?
-
Yes, from the audio info screenshot there it's bitstreaming using DSD64 using DoP via CoreAudio. DoP is the only way DSD can be played back in macOS as there's no native DSD playback support so at least that's what is to be expected.
Thanks for the quick reply. That's what I thought, but wanted to make 100% sure I wasn't losing my mind. Technically, I could still be losing my mind, but that's another story :~)
I'm using a Merging Technologies DAC and it isn't receiving DoP. Thus, my troubleshooting. I just received confirmation a couple minutes ago that the Merging Mac driver, called VAD, receives DoP and converts it to native DSD. No wonder my DAC wasn't receiving DoP.
-
I just received confirmation a couple minutes ago that the Merging Mac driver, called VAD, receives DoP and converts it to native DSD. No wonder my DAC wasn't receiving DoP.
Huh, that's pretty interesting. That's the first time I've ever heard of any app or driver being used to convert DoP to native DSD on macOS. I wonder how it works?
-
Huh, that's pretty interesting. That's the first time I've ever heard of any app or driver being used to convert DoP to native DSD on macOS. I wonder how it works?
I hear you loud and clear :~)
I spent countless hours troubleshooting the one. I'd never heard of this or even guess it was possible.
-
Thanks for the quick reply. That's what I thought, but wanted to make 100% sure I wasn't losing my mind. Technically, I could still be losing my mind, but that's another story :~)
I'm using a Merging Technologies DAC and it isn't receiving DoP. Thus, my troubleshooting. I just received confirmation a couple minutes ago that the Merging Mac driver, called VAD, receives DoP and converts it to native DSD. No wonder my DAC wasn't receiving DoP.
Was about to hop in and say this since I assumed you were wondering about your Merging gear.
Ravenna's way of transporting DSD is as native DSD (as an AES3 stream IIRC), not DoP.
Glad you got it sorted!
-
I can give you a general answer there...
Both DoP and "native DSD" deliver the actual original DSD bitstream - encapsulated into PCM - usually then sent via USB packets.
Therefore the DSD content sent by both is the same (and the same as the original DSD data stream).
The only difference is that "native DSD" uses the actual packet space more efficiently - while DoP is somewhat wasteful.
The result is that, for a given maximum USB data rate, you can send a higher "DSD rate" via "native DSP".
So, for example, a USB port capable of 768k PCM, can deliver DoP up to DSD256, but can deliver "native DSD" up to a higher limit (DSD512).
(I've heard that "native DSD" also includes a header flag identifying it as such... but that this is not always included.)
Since both formats deliver exactly the same DSD data to the DAC it's trivial to "convert between them".
(Or, more accurately, they both deliver the same DSD data stream once you extract them from the USB and PCM packets.)
Huh, that's pretty interesting. That's the first time I've ever heard of any app or driver being used to convert DoP to native DSD on macOS. I wonder how it works?
-
I can give you a general answer there...
Both DoP and "native DSD" deliver the actual original DSD bitstream - encapsulated into PCM - usually then sent via USB packets.
Therefore the DSD content sent by both is the same (and the same as the original DSD data stream).
The only difference is that "native DSD" uses the actual packet space more efficiently - while DoP is somewhat wasteful.
The result is that, for a given maximum USB data rate, you can send a higher "DSD rate" via "native DSP".
So, for example, a USB port capable of 768k PCM, can deliver DoP up to DSD256, but can deliver "native DSD" up to a higher limit (DSD512).
(I've heard that "native DSD" also includes a header flag identifying it as such... but that this is not always included.)
Since both formats deliver exactly the same DSD data to the DAC it's trivial to "convert between them".
(Or, more accurately, they both deliver the same DSD data stream once you extract them from the USB and PCM packets.)
Yes, I remember speaking at a debut of DoP in Hilversum, Netherlands back in 2011 at a dCS event. It's pretty cool.
I don't use USB in this system though and Merging's driver converting DoP to native DSD is problematic for one use case, but totally fine for all others. I just happened to run into the single problem child of wanting to output via the Merging HAPI AES outputs that don't support native DSD, only DoP, but I can't send the HAPI DoP becuase of the driver level conversion.