|
|
Post by Casey Leedom on Sept 11, 2018 16:47:39 GMT -5
By the way, the current RMC-1 Product Page says that the USB Type B Digital Audio Input will be capable of " UAC2 USB audio up to 24/192k" in the Specifications tab. That seems a bit slow. I wonder if that's a typo ... Casey |
|
|
|
Post by Casey Leedom on Sept 12, 2018 15:56:57 GMT -5
And if the RMC-1 truly is limited to 24bit/192kHz for its USB Type B Digital Input, that would seem to imply that the maximum DSD over PCM rate it could handle would be DSD64 since DSD128 requires PCM 352.8kHz packaging. Casey |
|
KeithL
Administrator 
Posts: 10,273
|
Post by KeithL on Sept 12, 2018 17:07:29 GMT -5
Actually, it just means that the highest PCM sample rate we're promising to support via USB at this point is 192k.  And if the RMC-1 truly is limited to 24bit/192kHz for its USB Type B Digital Input, that would seem to imply that the maximum DSD over PCM rate it could handle would be DSD64 since DSD128 requires PCM 352.8kHz packaging. Casey |
|
|
|
Post by Casey Leedom on Sept 12, 2018 17:10:46 GMT -5
KeithL, are you at liberty to say what USB chips you're using in the new XMC-2, RMC-1, and RMC-2 (AKA RMC-1L)? In grinding through the Linux support code I'm seeing several vendors which have wide-spread support for "Native DSD". For instance, XMOS ... Casey
|
|
|
|
Post by qdtjni on Sept 17, 2018 16:18:22 GMT -5
Actually, it just means that the highest PCM sample rate we're promising to support via USB at this point is 192k. And if the RMC-1 truly is limited to 24bit/192kHz for its USB Type B Digital Input, that would seem to imply that the maximum DSD over PCM rate it could handle would be DSD64 since DSD128 requires PCM 352.8kHz packaging. Casey At this point? Sounds a bit weird since the DACs already supports quite a bit more than that. This implies you either use a USB interface incapable of more or it is limited by SW. |
|
|
|
Post by Casey Leedom on Sept 17, 2018 16:30:46 GMT -5
I'm in the process of investigating what would need to be done on the RMC-1/XMC-2/RMC-1L size to allow for Native DSD. But I'm going to need to know what USB Interface chip is being used there I think. Of course they may be using the USB Host port on the Analog Devices ADSP SC573 ... Casey |
|
|
|
Post by Casey Leedom on Oct 18, 2018 14:31:34 GMT -5
By the way, there seems to be "some" indication that the "Native DSD" capability of the XMOS USB PHYs is possibly "on" by default in their Firmware. At least up to DSD128. See for instance the XMOS PDF document Enabling DSD256 in the USB Audio 2.0 Device Reference Design Software. It seems that the default Firmware configuration may support "Native DSD" up to DSD128 ... If the above is true, then the only thing which would need to happen in order to support "Native DSD" from Linux, would be to make sure that the correct USB (Vendor ID, Device ID) is in the Linux kernel sound/usb/quirks.c ... Casey |
|
|
|
Post by donh50 on Oct 18, 2018 18:46:46 GMT -5
I have designed a few delta-sigma converters though mostly RF/mW instead of audio. Delta-sigma is correct (per Dr. Gabor Temes, one of its fathers, who said the sigma-delta nomenclature was a mistranslation from a Japanese paper). Look at a block diagram of say a delta-sigma ADC and it is obvious the difference block (delta) comes before the summer (sigma). Virtually all delta-sigma audio converters include multi-bit quantizers inside the loop and most use a cascaded/MASH structure. They have their advantages and disadvantages but I see no point into diving into the whole audiophile debate on delta-sigma vs. non-oversampled (conventional) converters (a tip-off is that you can also oversample conventional converters and apply noise shaping, but without the loop the noise reduction as a function of oversampling ratio is much smaller, like 1/2 bit/octave of oversampling).
AFAIK except for things like ASIO and proprietary links the only way to do DSD through USB is to convert into PCM then convert back on the other end. That is the way I have always seen it done but not my day job so it could well be different now. The bits going in and out are the same, just have to deal with the latency (which is not an issue for consumer playback, and as has been said DAW's don't work with DSD anyway so again a non-issue).
FWIWFM - Don
|
|
|
|
Post by Casey Leedom on Oct 19, 2018 0:27:39 GMT -5
donh50 , You absolutely can do "Native DSD" from Linux. See sound/usb/quirks.c and all of the code and definitions surrounding deciding whether to do "Native DSD" or "DSD over PCM". The Linux-based Roon Bridge Raspberry Pi " RuPieee" distributions manages this quite nicely. Casey
|
|
|
|
Post by donh50 on Oct 19, 2018 8:36:21 GMT -5
donh50 , You absolutely can do "Native DSD" from Linux. See sound/usb/quirks.c and all of the code and definitions surrounding deciding whether to do "Native DSD" or "DSD over PCM". The Linux-based Roon Bridge Raspberry Pi " RuPieee" distributions manages this quite nicely. Casey Yes, of course, sorry I was thinking Windows and not Linux. Duh -- a Raspberry Pi3 is on my Christmas list. Senility. Again. And I am not even up on Windows -- not my area of expertise. |
|
