|
|
Post by Casey Leedom on Sept 4, 2018 20:47:03 GMT -5
I had naively assumed that DSD would normally be transferred over a USB Link in some sort of "native" [unmodified] format. And I had additionally assumed that using DSD over PCM (DoP) "packaging" of DSD Data over a PCM was at best a hack. But in the recent thread on How important is DSD support to you?, jdmusante referenced the DoP Open Standard from 2012 (last edit version 1.1, 2012/03/30). There are certainly some downsides to DoP — primarily being the bandwidth and frequency requirements it imposes as part of its PCM Hack, but other then that, it's just DSD Data packaged in a PCM Container. My question is: six years later, is there a "Native DSD over USB" format? Or is every USB device which claims DSD capability really talking about DoP? Casey |
|
|
|
Post by Casey Leedom on Sept 5, 2018 3:04:46 GMT -5
I did find a reference here to DSD being transmitted via UAC2's Raw Data Transfer Mode ... Casey |
|
|
|
Post by Casey Leedom on Sept 5, 2018 3:19:52 GMT -5
|
|
|
|
Post by mfeust on Sept 5, 2018 10:24:25 GMT -5
I did find a reference here to DSD being transmitted via UAC2's Raw Data Transfer Mode ... Casey You seem to be having a very nice conversation with yourself.  Mark |
|
|
|
Post by mgbpuff on Sept 5, 2018 10:37:08 GMT -5
I think DSD over USB is in fact DoP.
DSD over USB[edit]
An alternative to burning DSD files onto disks for eventual playback is to transfer the (non-encrypted) files from a computer to audio hardware over a digital link such as USB.
The USB audio 2.0 specification defined several formats for the more common PCM approach to digital audio, but did not define a format for DSD.
In 2012, representatives from many companies and others developed a standard to represent and detect DSD audio within the PCM frames defined in the USB specification; the standard, commonly known as "DSD over PCM", or "DoP", is suitable for other digital links that use PCM.[35] Many manufacturers now offer DACs that support DoP.
|
|
|
|
Post by Casey Leedom on Sept 5, 2018 10:45:16 GMT -5
You seem to be having a very nice conversation with yourself. Incremental research/not being able to sleep ... :-) Casey |
|
|
|
Post by Casey Leedom on Sept 5, 2018 10:48:36 GMT -5
I think DSD over USB is in fact DoP. DSD over USB[edit] An alternative to burning DSD files onto disks for eventual playback is to transfer the (non-encrypted) files from a computer to audio hardware over a digital link such as USB. The USB audio 2.0 specification defined several formats for the more common PCM approach to digital audio, but did not define a format for DSD. In 2012, representatives from many companies and others developed a standard to represent and detect DSD audio within the PCM frames defined in the USB specification; the standard, commonly known as "DSD over PCM", or "DoP", is suitable for other digital links that use PCM.[35] Many manufacturers now offer DACs that support DoP. Yeah, I did see that from the March 2012 DoP Open Standard. But that was 6 years ago and I was wondering if in the meantime the industry had moved on to a more "native" format. The XMOS document I pointed too seemed to indicate that there was an accepted "Native DSD" format for USB ... Casey |
|
|
|
Post by tme110 on Sept 5, 2018 17:45:12 GMT -5
On my system I can do DSD512 native over USB and DOP limited to DSD128 (maybe 256, I don't remember since I haven't used DOP in a year or so (but DOP has a max limit))
|
|
|
|
Post by Casey Leedom on Sept 5, 2018 17:51:55 GMT -5
On my system I can do DSD512 native over USB and DOP limited to DSD128 (maybe 256, I don't remember since I haven't used DOP in a year or so (but DOP has a max limit)) Ah, interesting tme110. What components do you have which do "Native DSD"? And what music server system are you using? Roon, DLNA, etc.? Casey |
|
|
|
Post by craigl59 on Sept 5, 2018 18:44:23 GMT -5
JRiver will output DSD in native format through a USB connection as long as it is going to a ASIO DAC. Do this easily with a RME ADI-2 DAC and it sounds as good as DSD ever does.
Do not care for DSD as a file format because of its lack of editing possibilities. In the studio, you have to transfer the file to a high-res PCM format in order to make edits. This makes no sense to me.
Have a number of classical recordings that were produced in DSD then issued with no post production. As a result, they have the expected cases of bad balances and soundstage problems.
Have been recording in 24/96 since the 1990s and have never been able to hear an improvement with DSD files over 24/96.
|
|
|
|
Post by tme110 on Sept 6, 2018 17:32:43 GMT -5
On my system I can do DSD512 native over USB and DOP limited to DSD128 (maybe 256, I don't remember since I haven't used DOP in a year or so (but DOP has a max limit)) Ah, interesting tme110. What components do you have which do "Native DSD"? And what music server system are you using? Roon, DLNA, etc.? Casey There's a few DACs that to it, even relatively inexpensive ones. I'm using ROON running on a sonic transporter which converts all files to 512DSD played in a Vinnie Rossi LIO integrated amp/dac. |
|
|
|
Post by Casey Leedom on Sept 6, 2018 17:52:28 GMT -5
Hhmmm, I was about to say that I thought that the Raspberry Pi RoPieee distribution only supported "Native DSD" but I see now that they've got support to do DSD over PCM (DoP) or "Native DSD": Native DSD streaming. It may do this automatically via the USB Device ID but that's not clear with a casual search. I definitely see issues being reported with regard to being limited to lower DSD rates using DoP ... Casey |
|
KeithL
Administrator 
Posts: 10,273
|
Post by KeithL on Sept 7, 2018 9:20:30 GMT -5
As far as I can see, in that regard, DSD has the same "benefits" and "drawbacks" as the old direct-to-disc vinyl records.
Drawback: You can't edit or mix it - or apply special effects. Benefit: You can't edit or mix it - or apply special effects.
In other words, by being impossible to edit directly, DSD prevents the producers from making complex mixes, or multi-track recordings, or using modern digital effects. So, for better or worse, when you buy a "real pure DSD recording" you are more likely to get a "simple, direct, un-engineered mix" (it's unlikely to be "over-processed"). You might even hope that, since there is little or no opportunity to "fix things in post", they've actually taken more care to get it right the first time. (Of course, the down-side of that is that nobody ever gets anything perfect the first time.)
It's up to you whether you consider this a benefit or a drawback.
However, it explains why you see very few complex multi-track recordings offered in DSD... and why they're sort of a waste of time when you do. Both because, if it's a complex multi-track recording, then it was mixed in PCM, and simply converted into DSD for "snob appeal" as "one more audiophile format to offer".
(Of course, if you really believe that PCM causes damage, then, by converting back and forth, you have simply compounded all of the harm done by both DSD and PCM, and added multiple conversions to the list of injuries.)
A number of programs these days will convert between DSD and PCM. jRiver will convert both ways; FooBar2000 will convert FROM DSD to PCM, and even from SACD ISO files (you'll need the free plugin), and then, of course, there's Korg AudioGate and Weiss Saracon (the two "big dogs" on the block). Quite a few programs these days, and some DACs, support DoP, and there are a few that support "native DSD" over ASIO.
I'm not even going to entertain a serious discussion about the presumed benefits of converting PCM content to DSD in the hopes of making it sound better. The real experts pretty much agree that the two formats are "audibly equal". However, if you really believe that PCM "causes some sort of harm", then converting your audio to DSD after it's already been damaged has no chance of undoing damage that's already been done.
Therefore, if it SEEMS to make an improvement, either: 1) maybe your particular DAC really does a better job converting DSD (because of some design quirk in the DAC) 2) maybe DSD is introducing some sort of coloration you like (in addition to the coloration already caused by the trip through "PCM-land") 3) maybe you're hearing tiny differences (artifacts) introduced by the conversion process itself (which is not bit-perfect) 4) maybe, when your DAC or pre/pro is in "pure DSD mode", some processing it normally applies to PCM content is disabled or bypassed, and that's the difference you hear 5) (maybe you're just imagining it)
My money would be on #3 or #4 (with the XMC-1, you are definitely bypassing several processing options when you choose to use a DSD input signal).
I should also note that, for anyone who really wants to hear for themselves, jRiver does convert from PCM to DSD. And, if you really want to play with all sorts of DSD and filter options, you should check out a program called HQPlayer by a company named Signalyst. It has all sorts of high-quality upsampling and filtering options. Of course, we all know that you can't make a digital audio signal more accurate or precise by using upsampling to add more fake information to the signal, but it's fun to play with.
(I should note that some of the options in HQPlayer require a massive amount of processing power... so a few of them will only work properly on a really powerful computer...)
JRiver will output DSD in native format through a USB connection as long as it is going to a ASIO DAC. Do this easily with a RME ADI-2 DAC and it sounds as good as DSD ever does. Do not care for DSD as a file format because of its lack of editing possibilities. In the studio, you have to transfer the file to a high-res PCM format in order to make edits. This makes no sense to me. Have a number of classical recordings that were produced in DSD then issued with no post production. As a result, they have the expected cases of bad balances and soundstage problems. Have been recording in 24/96 since the 1990s and have never been able to hear an improvement with DSD files over 24/96. |
|
KeithL
Administrator
Posts: 10,273
|
Post by KeithL on Sept 7, 2018 9:38:36 GMT -5
I also feel a need to make an interesting observation here.  Most modern DACs internally use a topology called Delta-Sigma (or Sigma-Delta). And fans of "multi-bit DACs" generally argue that this is bad - because it is a single-bit format.
While many of the same audiophiles seem to believe that DSD is good. Even though DSD is the file format equivalent of Delta-Sigma (a single-bit format). Which makes DSD pretty much the antithesis of "full multi-bit DACs". Isn't it funny how this stuff works out.  (The reality is that virtually all modern DACs are actually a sort of hybrid.... multi-bit Delta-Sigma DACs.)
As far as I can see, in that regard, DSD has the same "benefits" and "drawbacks" as the old direct-to-disc vinyl records. Drawback: You can't edit or mix it - or apply special effects. Benefit: You can't edit or mix it - or apply special effects.
In other words, by being impossible to edit directly, DSD prevents the producers from making complex mixes, or multi-track recordings, or using modern digital effects. So, for better or worse, when you buy a "real pure DSD recording" you are more likely to get a "simple, direct, un-engineered mix" (it's unlikely to be "over-processed"). You might even hope that, since there is little or no opportunity to "fix things in post", they've actually taken more care to get it right the first time. (Of course, the down-side of that is that nobody ever gets anything perfect the first time.)
It's up to you whether you consider this a benefit or a drawback. However, it explains why you see very few complex multi-track recordings offered in DSD... and why they're sort of a waste of time when you do. Both because, if it's a complex multi-track recording, then it was mixed in PCM, and simply converted into DSD for "snob appeal" as "one more audiophile format to offer".
(Of course, if you really believe that PCM causes damage, then, by converting back and forth, you have simply compounded all of the harm done by both DSD and PCM, and added multiple conversions to the list of injuries.)
A number of programs these days will convert between DSD and PCM. jRiver will convert both ways; FooBar2000 will convert FROM DSD to PCM, and even from SACD ISO files (you'll need the free plugin), and then, of course, there's Korg AudioGate and Weiss Saracon (the two "big dogs" on the block). Quite a few programs these days, and some DACs, support DoP, and there are a few that support "native DSD" over ASIO. I'm not even going to entertain a serious discussion about the presumed benefits of converting PCM content to DSD in the hopes of making it sound better. The real experts pretty much agree that the two formats are "audibly equal". However, if you really believe that PCM "causes some sort of harm", then converting your audio to DSD after it's already been damaged has no chance of undoing damage that's already been done. Therefore, if it SEEMS to make an improvement, either: 1) maybe your particular DAC really does a better job converting DSD (because of some design quirk in the DAC) 2) maybe DSD is introducing some sort of coloration you like (in addition to the coloration already caused by the trip through "PCM-land") 3) maybe you're hearing tiny differences (artifacts) introduced by the conversion process itself (which is not bit-perfect) 4) maybe, when your DAC or pre/pro is in "pure DSD mode", some processing it normally applies to PCM content is disabled or bypassed, and that's the difference you hear 5) (maybe you're just imagining it)
My money would be on #3 or #4 (with the XMC-1, you are definitely bypassing several processing options when you choose to use a DSD input signal). I should also note that, for anyone who really wants to hear for themselves, jRiver does convert from PCM to DSD. And, if you really want to play with all sorts of DSD and filter options, you should check out a program called HQPlayer by a company named Signalyst. It has all sorts of high-quality upsampling and filtering options. Of course, we all know that you can't make a digital audio signal more accurate or precise by using upsampling to add more fake information to the signal, but it's fun to play with.
(I should note that some of the options in HQPlayer require a massive amount of processing power... so a few of them will only work properly on a really powerful computer...)
JRiver will output DSD in native format through a USB connection as long as it is going to a ASIO DAC. Do this easily with a RME ADI-2 DAC and it sounds as good as DSD ever does. Do not care for DSD as a file format because of its lack of editing possibilities. In the studio, you have to transfer the file to a high-res PCM format in order to make edits. This makes no sense to me. Have a number of classical recordings that were produced in DSD then issued with no post production. As a result, they have the expected cases of bad balances and soundstage problems. Have been recording in 24/96 since the 1990s and have never been able to hear an improvement with DSD files over 24/96. |
|
|
|
Post by Casey Leedom on Sept 7, 2018 10:37:39 GMT -5
Yes, let me make it clear: I think that this DSD nonsense is ... well, nonsense. That said, I'm forced to deal with the DSD issue because my partner in crime is a DSD Idiot and is flooding our collection with every DSD he can lay his hands on. (sigh) And they're stupidly large as well.
In any case, back to the original topic. I've found where in Linux it identifies a Device as being capable of Native DSD or needing the DSD Date to be packaged in PCM Frames. If you'll look at sound/usb/quirks.c you'll see a number of routines to decode whether a USB Device is capable of "Native DSD" and what USB Commands it may need to switch between "Native DSD" and PCM.
So Linux and the Raspberry Pi RoPieee distribution have the ability to automatically handle this as long as the USB Device presents a unique USB Device ID. So my advice to Emotiva is that regardless of their current plans for supporting/not supporting "Native DSD", you should make sure that the XMC-2, RMC-1, and RMC-2 all present non-generic USB Device IDs. Then, if you're not currently going to support "Native DSD" and you get around to supporting "Native DSD" at a later point, I guess you'd need to change that USB Device ID in order to have a way for USB Hosts to do the right thing automatically.
Casey
|
|
|
|
Post by garbulky on Sept 7, 2018 10:39:28 GMT -5
Yes, let me make it clear: I think that this DSD nonsense is ... well, nonsense. That said, I'm forced to deal with the DSD issue because my partner in crime is a DSD Idiot and is flooding our collection with every DSD he can lay his hands on. (sigh) And they're stupidly large as well. In any case, back to the original topic. I've found where in Linux it identifies a Device as being capable of Native DSD or needing the DSD Date to be packaged in PCM Frames. If you'll look at sound/usb/quirks.c you'll see a number of routines to decode whether a USB Device is capable of "Native DSD" and what USB Commands it may need to switch between "Native DSD" and PCM. So Linux and the Raspberry Pi RoPieee distribution have the ability to automatically handle this as long as the USB Device presents a unique USB Device ID. So my advice to Emotiva is that regardless of their current plans for supporting/not supporting "Native DSD", you should make sure that the XMC-2, RMC-1, and RMC-2 all present non-generic USB Device IDs. Then, if you're not currently going to support "Native DSD" and you get around to supporting "Native DSD" at a later point, I guess you'd need to change that USB Device ID in order to have a way for USB Hosts to do the right thing automatically. Casey Your partner is into audio as well?! Including DSD?! Nice! My wife likes audio too but definitely not enough to get into formats. I have finally indoctrinated her into being able to tell people "this recording is lossless and high res". But I'm not sure she knows what that means.  |
|
|
|
Post by pawsman on Sept 7, 2018 12:26:16 GMT -5
"However, it explains why you see very few complex multi-track recordings offered in DSD... and why they're sort of a waste of time when you do.
Both because, if it's a complex multi-track recording, then it was mixed in PCM, and simply converted into DSD for "snob appeal" as "one more audiophile format to offer".
Keith,
This is true most of the time; but not with the 4 channel Pentatone SACDs that were made from discrete quadaphonic analog master tapes from the 1970s.
Pentatone acquired rights from Philips, DG and others to their Quadraphonic analog master tapes recorded mostly in the 1970s. The 4 channel master tapes
are converted directly to DSD, as part of their RQR Series. These Pentatone Hybrid SACDS are some of the best sounding CDs made, IMO.
pawsman
|
|
|
|
Post by craigl59 on Sept 7, 2018 13:48:46 GMT -5
pawsman:
Agree completely, you are spot on.
Have been acquiring as many SACDs as possible that are 4-channel quad reissues and they all sound superb (Doors, Blue Oyster Cult, etc.). The 1970s quad revolution did not at all mind sending significant content to the back speakers and this makes listening fun.
Just got the SACD re-issue of Rheinberger Organ Concertos by Biggs and the CSO; this is the infamous 1973 release that was pulled by Columbia immediately because of complaints from the Rheinberger family over copyright payments. The SACD version is a direct copy of the original quad release that, I think, was never issued at all. It sounds grand, showcasing Bigg's Flentrop pipe organ and the Columbia Symphony in superb detail. Will shake your listening room and test even high-end gear.
Would like to see more Quad reissues and wonder if there is a comprehensive list of those done so far somewhere.
|
|
|
|
Post by jmilton on Sept 7, 2018 20:49:54 GMT -5
pawsman: Agree completely, you are spot on. Have been acquiring as many SACDs as possible that are 4-channel quad reissues and they all sound superb (Doors, Blue Oyster Cult, etc.). The 1970s quad revolution did not at all mind sending significant content to the back speakers and this makes listening fun. Just got the SACD re-issue of Rheinberger Organ Concertos by Biggs and the CSO; this is the infamous 1973 release that was pulled by Columbia immediately because of complaints from the Rheinberger family over copyright payments. The SACD version is a direct copy of the original quad release that, I think, was never issued at all. It sounds grand, showcasing Bigg's Flentrop pipe organ and the Columbia Symphony in superb detail. Will shake your listening room and test even high-end gear. Would like to see more Quad reissues and wonder if there is a comprehensive list of those done so far somewhere. The organ is not D.A.Flentrop and Sons. Its a Möller...and it does sound awesome sauce. |
|
|
|
Post by Casey Leedom on Sept 11, 2018 13:23:36 GMT -5
So I'm starting down the path to see what needs to be done on the Device side of things in the Linux Kernel in order to support Native DSD. Earlier I found the Host side code which handles determining when a downstream USB Device can support Native DSD versus DSD over PCM (DoP). This code is in sound/usb/quirks.c and is based on triggering off of the USB Vendor and Device IDs. For instance, the Teac UD-503 and NT-503 support Native DSD and this is noted in the is_itf_usb_dsd_dac() function with a switch-case of USB_ID(0x0644, 0x8043) where 0x0644 is Teac's USB Vendor ID and 0x8043 is the USB Device ID for "TEAC UD-501/UD-501V2/UD-503/NT-503" as noted in the comment for the switch-case. (This function returns "true" if a USB Device needs a Vendor Command in order to switch between PCM and Native DSD.) And there are other checks for these USB Vendor and Device IDs in the code under sound/usb/. Another routine in quirks.c that plays an important role in determining which USB Devices support Native DSD is snd_usb_interface_dsd_format_quirks() ... The list of USB Devices which support Native DSD is surprisingly quite large ... If we want to support Native DSD to the Emotiva RMC-1, RMC-2 (AKA RMC-1L), and XMC-2, we'd need similar USB Host side code to check for the Emotiva USB Vendor ID and the Device IDs for these products. Which brings up the question: what is the Emotiva USB Vendor ID? I can't find any registered USB Vendor ID for Emotiva, let alone any USB Device IDs for things like the XMC-1. Does anyone have an XMC-1 connected to a Linux system and can look at the output of "lsusb"? And another question is: what USB chip(s) are in the Emotiva products? In any case, presuming we can get the missing USB Vendor/Device ID issue addressed, then there's the question of what needs to be done on the Device side in order to support Native DSD? Onward to victory ... Casey |
|
