Is native DSD input supported via USB?
I’m using RoPieee as a Roon bridge connect DirectStream via USB. Can’t seem to select native DSD. Wanted to confirm if native DSD via USB is supported.
Thanks !
The DirectStream USB drivers don’t support native DSD. USB in general supports native DSD. Just in case it’s not obvious DoP gets the exact same bits to the DAC and the DS converts native DSD to DoP internally so getting native DSD to the DS in particular isn’t as much of an advantage as it might be in some other DACs.
2 Likes
Thanks Ted for the info. Just upgraded to sunlight. Love the new version!!
By “DirectStream USB driver,” I assume you mean PS Audio’s ASIO driver specifically? Since Windows finally went UAC2 compliant (since release 1703), I assume (so many assumptions, sorry), that using WASAPI (exclusive of course) would allow for direct streaming of native DSD over USB?
My SGCD will recognize DSD presented over USB via DoP with a nice little display identifier that says “DSD”. 2 Channel only, of course.
Yeah - I use DoP to fiddle with DSD files. Only to play around though. I have a few free DSD files that I’m not really interested in listening to for enjoyment, and I haven’t had/found the urge/need to buy music in DSD, so it’s more an academic curiosity to me. I am also aware that if I do eventually get DSD files I want to listen to, I would have no issue (personally) using DoP, since there’s really no difference in how the DAC processes the data.
It’s interesting to note that in the specs, under Data Handling, they note the ability of using raw (native) DSD over USB:
But the indication under USB Digital Input states only DoP:
So is it a limitation of the input hardware (Xmos), driver (PS Audio ASIO), or both?
The PS Audio USB driver is from Thesycon, the driver proper is lower level than ASIO, WASAPI, etc. Thesycon’s ASIO driver, their WASAPI, driver, etc. all use the lower level driver. But this is really not the issue. The code in the XMOS chip in the DS has native DSD disabled. It’s sort of a historical accident, but the original XMOS code that PS Audio used didn’t support Native DSD. When it did support native DSD it unfortunately also had clicks and pops at the transition between PCM and native DSD which it didn’t have when going between PCM and DoP. It has been updated by PS Audio in the mean time, but I believe the XMOS code still had native DSD disabled.
You can now use the native Windows drivers with the DS, but when I tried it they just weren’t as reliable as the Thesycon drivers.
1 Like
Thanks for the info. So the only really reliable way to stream native DSD is via i2s then?
Reliable is an interesting term. I am currently using the USB input and am streaming DSD.
Yes, the DS only supports native DSD thru I2S.
1 Like
DoP or native? Many software and hardware options do DoP by default, and have to be set to do native. For example, JRiver’s default is to do DoP, but it can be set to native. An i2s streamer I built using a Pi4 and hats by IanCanada also had hardware DoP set as default (that has to be switched off on the board if native is desired).
I don’t know if it’s relevant to your “quest” but many of us use the Matrix X-SPDIF 2 to convert USB to I2S (or XLR, etc.) to the DS. The Matrix accepts native DSD over USB (and supports DSD256 which the DS’s XMOS doesn’t support) and send the I2S to the DS.
1 Like
So it’s likely DoP (which can still be losless) since according to @tedsmith:
“Yes, the DS only supports native DSD thru I2S.”
as native DSD capability of the XMOS chip is disabled:
“The code in the XMOS chip in the DS has native DSD disabled.”
So only DoP can get through via USB.
@tak1313 How did you find IanCandada solution? Has been looking at it. But I’m not too sure if RoPieee recognised it. What OS did you run the Pi on?
In THEORY, for the DS, you really only need the HDMIPi since the DS doesn’t need the MCLK which the Pi doesn’t have natively, so that’s a cheap way to try it out - a Pi 4 plus the HDMIPi still comes in around $100ish. The HDMI Pi is PS Audio compatible and does not set a false pre-emphasis flag. Not sure what bit/sample rates it would be capable of without the FifoPi off hand since I’ve always ran it with it. I got the FifoPi in case I decided to get another DAC that needed accurate clocking from the source.
The FifoPi comes with decent clocks so you can make sure it works, but Ian recommends replacing them with better clocks. I replaced them with Crystek CCHD957s. He sells the boards to do the swap, but you’re on your own with the SMD capacitors and clocks (or you may be able to find a repair shop that would do it for you at a modest price). The clock boards come with the necessary capacitors.
The FifoPi also has hardware DoP processing (which you can defeat). The FifoPi is NOT an output hat. You would still need either the TransportPi which also has S/Pdif in coax and optical along with i2s LVDS, or the HDMIPi, which only has i2s LVDS.
Another advantage of using the FifoPi before the TransportPi or HDMIPi is it also has an isolated GPIO so you can power the output boards with an isolated 3.3v supply, and you also have the option of powering both the FifoPi and the Pi itself with an outboard supply through an onboard connector (instead of through the USB C port).
There are two flaws I have found.
-
There tends to be some clicks/mild popping when switching tracks with different bit/sample rates. Based on the behavior, I believe it has to do with the FifoPi switching clocks, but I haven’t gotten around to mounting the HDMIPi directly to see.
-
Using JRiver, I had to set a 1/4 second delay to allow for hardware sync, or it could periodically drop the first few milliseconds of a track with higher bit/sample rates. But this occured ONLY when streaming Qobuz. It doesn’t occur with local files with JRiver. I use BubbleUpnp as a controller to stream Qobuz, so right now, I’m not sure if it’s a Qobuz problem, a Qobuz through Bubble problem, or a Qobuz through Bubble through JRiver problem.
I’m pretty sure it’s the last one, because if I use Bubble to send Qobuz directly to the Bridge, there’s no problem.
I forgot to answer your other question. I run the current Raspbian Bullseye (newer 64 bit OS), along with JRiver as stated. The JRiver allows the Pi to appear as a renderer in Bubble.
In order for the hats to run properly, you have to activate the dtoverly for the Hifiberry DAC, which sends the necessary signals through the GPIO.
I have read others state they used the dtoverlay for the Hifiberry DAC Plus, but I haven’t been able to get JRiver to recognize it as an output option if I use that overlay - but it might be a JRiver thing as well.
I don’t know how RoPieee is, never tried it, but I’m pretty sure it would work because I can’t see that it WOULDN’T work with a HifiBerry DAC.