Compatible I2S source devices

Ted Smith said Blanket statements like "remove the USB noise" are an over simplification. That box is using the same tech as the DS, whether it removes more noise from USB will be system specific. Some people get great USB results in their systems with minimal work while others go to heroic efforts. Just as some get much better sound with the Bridge and others get better sound with USB. IMO pick the way you want to use the DS (or any DAC) then optimize your system for the way you use it. I prefer the user experiences that I get connected with USB so I concentrate my efforts there. Others prefer various UPnP control interfaces so they tend to use the Bridge.
OK. Further on ground loops, do you recommend lifting the ground on the power cord for the DS? I know the PS Audio power cords allow you to unscrew the ground prong (I tried an AC 5 albeit with ground and didn't quite like it). Alternatively on other power cords I can use a cheater plug or ground lift adapter. There is no danger with doing this I presume?
yacheah said OK. Further on ground loops, do you recommend lifting the ground on the power cord for the DS? I know the PS Audio power cords allow you to unscrew the ground prong (I tried an AC 5 albeit with ground and didn't quite like it). Alternatively on other power cords I can use a cheater plug or ground lift adapter. There is no danger with doing this I presume?
"There is no danger with doing this I presume?" There is a danger, that's why they are there. When everything is working properly you don't need the ground pins on the AC, but when something goes wrong with the power supply, other wiring, etc. the ground pin is what keeps live AC from showing up on the cases. People do get electrocuted by lifting their ground pins and getting unlucky. Using a cheater plug is a fine way of narrowing down a ground loop, but it's not a proper fix. If you have any pets or children you care about I wouldn't leave a ground pin disconnected.

A proper fix that both preserves safety and helps with sound quality is to use dedicated circuits with solid grounding of the outlets. Another are the (some very expensive) ground boxes with which you run very solid star ground wires from each of your devices to a central well grounded unit. By providing a lower impedance path from each unit to the ground you attempt to keep much leakage current from running in your interconnects, etc.

Ted Smith said Blanket statements like "remove the USB noise" are an over simplification. That box is using the same tech as the DS, whether it removes more noise from USB will be system specific. Some people get great USB results in their systems with minimal work while others go to heroic efforts. Just as some get much better sound with the Bridge and others get better sound with USB. IMO pick the way you want to use the DS (or any DAC) then optimize your system for the way you use it. I prefer the user experiences that I get connected with USB so I concentrate my efforts there. Others prefer various UPnP control interfaces so they tend to use the Bridge.
I've considered one of the USB->I2S boxes like the one mentioned in an earlier post, but haven't actually tried one yet because they often use the same USB receiver that is already in the DS and that seems redundant to me.

My system is simple; I mostly feed my DS via USB with an old Acer Nav50 netbook running Audiophile Linux 3.1, which comes with Cantata MPD and it has run flawlessly with the DS from day-1. No need for this driver or that driver, Linux has been compatible with high-definition audio for a while now. I chose that particular Acer because it came with a single-core 64-bit Intel Atom N450, which easily handles stereo DSD128 and DXD and Bryston used the same chip in one of their DACs, so I figured it must be OK. I did put one of the new Samsung SSDs in it to store music, which cost about 3x what the refurbished netbook cost.

Now to the interesting bit regarding optimizing USB … well, interesting to me, anyway. I disabled the Acer’s wi-fi since I wasn’t using it, and the DS sounded better. Not a huge difference, but clearly better. No measurements were taken, but I suspected it was due to lower digital noise. So what else could I disable? Well, the Acer is basically split into two boards, the main CPU motherboard and a separate board that houses the ethernet, the audio DAC and related amplifier and ports, and a third USB port. So I decided to remove the second board to see if the Acer would still run and whether I could hear a difference. (I also pulled the CPU fan and related cooling apparatus and replaced it with a heat-sink, which required cutting a hole in the bottom of the plastic chassis … yes, I am that crazy.)

BUT, not only did it run, but the DS sounded fantastic. Better, smoother, more “organic” top to bottom. I was quite surprised at the difference, and suspect it would be on par with adding something like the Regen or Intona. I would like to try the Intona for ground isolation at some point, and a higher end source too, but for now my stripped down Acer netbook and DS are doing the job for me.

Minimalist said I've considered one of the USB->I2S boxes like the one mentioned in an earlier post, but haven't actually tried one yet because they often use the same USB receiver that is already in the DS and that seems redundant to me.
yacheah said

Some DS users locally have reported good results with this USB to I2S bridge/ adapter if you can call it that.

http://www.shenzhenaudio.com/singxer-su-1-usb-digital-interface-with-xmos-xu208-cpld-dsd256-dop.html

This would remove the USB noise I presume? But I guess it is best to have an I2S source?


I am not a big friend of such USB to I2S boxes anymore after I had a Hydra Z and a Gustard U12 here. Though I would like to give the Singxer SU-1 a try due the interesting specs. The Hydra makes the most sense together with the Audiobyte Black Dragon imho.

Personally, I still like the Raspberry + Audio-GD I2S-to-HDMI solution.

Holzohr said
Minimalist said I've considered one of the USB->I2S boxes like the one mentioned in an earlier post, but haven't actually tried one yet because they often use the same USB receiver that is already in the DS and that seems redundant to me.
yacheah said

Some DS users locally have reported good results with this USB to I2S bridge/ adapter if you can call it that.

http://www.shenzhenaudio.com/singxer-su-1-usb-digital-interface-with-xmos-xu208-cpld-dsd256-dop.html

This would remove the USB noise I presume? But I guess it is best to have an I2S source?

I am not a big friend of such USB to I2S boxes anymore after I had a Hydra Z and a Gustard U12 here. Though I would like to give the Singxer SU-1 a try due the interesting specs. The Hydra makes the most sense together with the Audiobyte Black Dragon imho.

Personally, I still like the Raspberry + Audio-GD I2S-to-HDMI solution.


I’d avoid the rube-goldberg USB solutions like the plague, including the lan-rover (unless thats the only option, that actually looks good). Stay pure i2s or SPDIF if you can. USB at the start kills the simplicity of those.

1 Like

I may have missed it, but do any of these i2s to HDMI solutions yet support DSD 2x?

tony22 said I may have missed it, but do any of these i2s to HDMI solutions yet support DSD 2x?
The USB to I2S/HDMI solutions support DSD128 and DSD256 (Hydra & Singxer). The Raspberry/Audio-GD package only supports DSD64.

I just have ordered an Ethernet to USB solution, the SOtM sMS-200.

Who is limiting to DSD 64, Raspberry or Audio GD I2s ?

Thanks,

Alexandre.

Hi Alexandre, that’s a good question. All I know is the Raspberry can deliver DSD128 via USB. I guess it is due the DoP thing. The piCorePlayer doesn’t support native DSD, neither Roon afaik. So, DSD128 gets converted to PCM 176.4 khz via the Audio-GD I2S module.

Holzohr said Hi Alexandre, that's a good question. All I know is the Raspberry can deliver DSD128 via USB. I guess it is due the DoP thing. The piCorePlayer doesn't support native DSD, neither Roon afaik. So, DSD128 gets converted to PCM 176.4 khz via the Audio-GD I2S module.
Hi Holzohr,

the Audio-GD output module doesn’t process anything, it just balances the signal from the Pi pins to LVDS format, so it travels in the HDMI cable (made for a symmetric signal to travel since connectors are in twisted pairs)

It’s the player software that converts native DSD to DOP

I’ve wondered myself where was the limit coming from, and without equipment to measure noise at DSD64 and DSD128 frequencies we won’t have an answer.

The player seems to keep playing the file so I suppose our home-made unshielded connections from the Pi to the Audio GD board pick up/generate too much noise at DSD128 for the signal to be decoded at the other side.

I now use a 50cm HDMI cable and this made no change.

If anybody has any talent at desgning boards we could try to design a piggy back board for the Pi to have shortest signal path for HDMI I2S output…

Schematics would look like that: (Pi connector is on the right)

Hi Linvincible, unfortunately I am free of any talent in this field. sad-029_gif

Btw, please have a look what Jesus has posted a couple of weeks ago: ds and source clock

What do you think about this solution with a Hifiberry DAC+ Pro “between” the Pi and the Audio-GD module? I have ordered such a bundle with Raspberry 3 and Hifiberry DAC+ Pro. Though it is rather a try to make the Raspberry to a I2S-ready “Roon Bridge”.

Mario

Hi Guys,

I already had a suspiction about the PicorePlayer and also post a question in his website long ago, but so far I get no answer.

So the hdmi cable from an nvidia gfx 970 can connect to the perfectwave directstream dac w/bridge?

kaeksen said So the hdmi cable from an nvidia gfx 970 can connect to the perfectwave directstream dac w/bridge?
This will not work, kaeksen - however the HDMI cable itself will work for transfer of I2s signals to your new DAC that currently is shipping.

I don’t think so. I’m not familiar with the nvidia gfx 970, but did a search and the closest thing is a gtx 970 which a video only card. Best I could tell there isn’t any audio output. The I2S connection on the DS uses an HDMI cable but IS NOT an HDMI compatible audio connection. It is a digital audio only format. The use of an HDMI cable was for simplicities sake.

Edit: Frode beat me to the punch …

Ted Smith said

A proper fix that both preserves safety and helps with sound quality is to use dedicated circuits with solid grounding of the outlets. Another are the (some very expensive) ground boxes with which you run very solid star ground wires from each of your devices to a central well grounded unit. By providing a lower impedance path from each unit to the ground you attempt to keep much leakage current from running in your interconnects, etc.


I have seen Aural Symphonics SPDIF cables with a ground wire which you separately connect to a chassis ground. Is this effective in a similar way?

Yes it can be, having a lower impedance ground wire can conduct stray current a little farther away from things that might be sensitive.

Hi Amolan,

I now think it’s the Pi that’s the limit in I2S output to DSD64, the Audio-Gd module specs go at a very high bitrate on their website (32 bit / 384K)

I’ll try on an Odroid C2 that has more power than the Pi, unfortunately picoreplayer not available for it, will have to use Volumio for the test.

amolan said Hi Guys,

I already had a suspiction about the PicorePlayer and also post a question in his website long ago, but so far I get no answer.

roon_audio_settings2.jpg

Linvincible said Hi Amolan,

I now think it’s the Pi that’s the limit in I2S output to DSD64, the Audio-Gd module specs go at a very high bitrate on their website (32 bit / 384K)

I’ll try on an Odroid C2 that has more power than the Pi, unfortunately picoreplayer not available for it, will have to use Volumio for the test.

amolan said Hi Guys,

I already had a suspiction about the PicorePlayer and also post a question in his website long ago, but so far I get no answer.

Hi Linvincible,

In fact the real issue is under linux kernel, you will find somewhere in this forum below your answer

Is there a solution with a custom kernel but I didn’t tryed yet.

Regards,

Alexandre.