TarnishedEars, based on Teds input I did manage to turn off demphasis by covering up pin 15 see that other Oppo dsd thread
1 Like
When using one of the I2S inputs on the DirectStream, does the DirectStream use its own clock or the I2S device’s clock feeding the DirectStream? In other words, sound quality at the mercy of the clock in the external I2S device?
The DS doesn’t use the clocks from any inputs. In particular it doesn’t even hook the Master Clock inputs from the I2S connectors to anything. It instead looks for patterns in the incoming data, puts the incoming samples in a buffer and only pays attention to the rate of the incoming bits (e.g. are things coming in at, say, 44.1k samples / second.)
2 Likes
I’m working on identifying the trace to the demphasis pin now. And its looking tricker than I had first guessed. So cross your fingers for me.
Is it better to use the DirectStream’s USB or I2S interface to feed it PCM and DSD content? Specifically, all things being equal, is it better to use a streamer with an I2S output or with a USB output?
You’ll get a lot of different opinions on this. I think you can tweak any input and get great sound.
Some think that the bridge has a leg up (i.e. take less tweaking for than other inputs to get to a particular level of sound.)
If TOSLink has the bandwidth you need it could well be the best input since it doesn’t have any groundloop issues. With equivalent grounding S/PDIF, AES/EBU and I2S are all the same, tho getting as good of grounding on S/PDIF as I2S isn’t straight forward. USB can easily be the worst in untweaked sound quality, but it’s certainly got the most bandwidth, works with essentially all current personal computers, etc. and often is easier to get working the first time than the bridge.
I use USB most of the time and am happy with the sound I get. Not that I think everyone should tweak the same, but I use the Corning 3.Optical USB cable and/or a USB hub with it’s own good power supply just before the DS.
If you have an I2S source it’s a quick and easy way to get great sound. If you don’t, personally I’d get USB, AES/EBU or S/PDIF going before buying some kind of I2S interface.
If you were buying an Ethernet-based streamer, and the various output types (AES, SPDIF, I2S, and USB) all cost the same, what would be best from an absolute sound quality perspective?
Wouldn’t I2S require the least amount of work from the DAC? Or are all the interfaces basically the same in that regard?
The world is different in FPGA land - all inputs are always running in parallel, whether they have incoming data or not. Unlike a general purpose processor in an FPGA EVERYTHING is always running. (For you programmers: both arms of an if, all arms of a case or switch statement, etc. are run in parallel. The code just picks the answer from them that it’s interested in.)
If an internet streamer has all output options at the same price (and the required cables are the same price) and you know absolutely that the I2S input is PS Audio compatible the I2S option wouldn’t be the worst choice. (It would be the easiest to get sounding the best.)
2 Likes
Hi Jim, did you complete your streamer ? And have you some comparative feddbacks with other materials ?
On my side I’ve added some isolation walls in my streamer and filtering caps. Very good results to my hears.
I’m thinking on the replacement of my NanoPI Neo by the NanoPI Neo2 (same form factor) which could, I hope so, be easier to patch the Linux Kernel with the necessary for native DSD support.
1 Like
hi Patrick,
in first place i am not Jim, it’s just PS Audio’s forums issue which somehow mixed usernames or whatever 
I am still maniac 
And yes i have finished (or almost) the streamer. I even started to write down some kind of description but due to lack of time i haven’t finished it.
Listening impressions (together with my good-eared friend) were positive - Roon via this streamer sounds as good as UPnP via Bridge2. However UPnP via this streamer sounds even better. So I have achieved my goal on partially as I ultimately wanted to have Roon to have same SQ as UPnP
So here is what I was able to put down for now:
Coppermine DYI digital audio transport project
Intention: to build a high-end streamer with eventual possibility to replace RPI SOC with something better suited in the future.
Thanks to: “patrick” from PS Audio forums for inspiration and support and “br” for tuned version of picoreplayer + listening tests
Supported protocols: OpenHome, UpNP and Roon . Potential to include Airplay and Spotify Connect in future.
Supported outputs: Coaxial (up to 192kHz 24bit) and I2S (up to 384kHz 32bit / DSD256) via HDMI PS Audio standard
Features:
- switch adjustable 3 Ground modes:
- RPI grounded to case
- case grounded via RPI PSU only (no ground to RPI itself), no grounds between components, no ground on I2S output
- RPI + Hecate grounded to case (required for Hecate detection by RPI after power-on and reboot)
- Copper case to effectively eliminate EMI/RFI impact on internal components
- All three component chambers shielded from each other by copper plates + conductive copper tape on junctions
- Shielded power cables and USB data-only cable between RPI and Hecate
- ssh access
SW details:
- heavily tuned PiCorePlayer (TinyCoreLinux based distro) , specifically for RPI3 quad-core SOC - thanks to my friend “br”
- underclocking, undervoltage, disabled all unnecessary hardware, kernel modules and processes, tuned kernel buffers, process priorities and affinity to cpu cores
- upmpdcli + mpd
- roonbridge with semiautomatic upgrades supported (user intervention required)
Copper case:
- two 20x20cm copper plates (2mm thick) for top and bottom plate
- two 20x20cm cooper plates (1mm thick) - one used for side plates and internal component separation plates
Powe Supply Units:
- Linear PSU for RPI3 (5V 3A)
- two separate Linear PSUs 5V 1,5A for Hecate and I2S output module
Connectors / adadpters:
- Neutrik Etherner panel connector
- Neutrik HDMI panel connector
- Neutrik USB B to A panel connector
- HDMI golden platted gender changer (male to male)
- two barrel panel connectors for power input
- two USB A connectors
- micro USB connector
- USB B connector for rpi power input
Boards:
- Raspberry PI3
- standard board with original heatsinks
- Armature Hecate DYI version (to allow I2S output)
- provides re-clocked SPDIF/I2S output galvanic isolated from RPI
- Xmos Xcore 208 ; two Crystek CCHD-575-25 clocks ; Xilinx 9572XL
- GD Audio I2S HDMI lvds output module
- 3,3V LDOVR LT3045-S Ultra Low Noise LDO Voltage Regulator
- 5V LDOVR LT3045-A Ultra Low Noise LDO Voltage Regulator
Cables:
- 1 meter of shielded twister pair cable
- 15 cm of shielded CAT5e cable
- 30 cm of cable for GNDs
Misc:
- 2 metes of Self-adhesive Copper tape for EMI/RFI shielding (adhesive must be conductive)
- 2-pole 3-way switch (ON-OFF-ON) for GND selection
- 5cm of 6mm aluminium (or other metal) plate for corners allowing mounting of top plate
- 2 meters of 5mm brass L-profiles
- 4 brass M3 screws
- 12 polypropylene stands (radius 2.5mm, height 1cm)
- 12 2,5mm x 5mm screws
- 6 2,5mm/3mm screws for connectors
- transparent silicone feet
Tools:
- iron saw
- epoxid based glue
- iron rasp
- iron grinder for case finish
- iron drill (3,5mm, 6mm, 8mm, 24 mm)
Photos:
Final:
5 Likes
Hi Maniac, I had a huge doubt you became Jim, but… 
Very impressive work, we should setup a dedicated web site/blog with all our experiences (primary goal, expectations, design, tools, insights). Should be interesting.
Interesting the idea of the switch for different grounds configuration. Do you prefer one over the others ?
On my picture, you can see I definitively choosen to ground the box with the HDMI output module. Hope it was the best choice 
it is quite strange, however i believe what i am hearing is that I get best SQ with no grounds connected 
I still plan to shield 99% of time unused Coax connector with copper pipe, i just must find place to buy steep M16 nut or tools to make steep M16 thread on piece of copper pipe i have
Also what i have found out is that even the grounds are not connected i can still hear leakage of EMI from RPI going to HDMI output - either the case is not shielding enough, or it get there somehow via the usb data cable from RPI to Hecate . However as i signifficantly underclocked and undervoltaged RPI (up to the stability limits) , the EMI leakage got much better…
Also quite interesting fact is that i have discovered that even as the USB cable powering RPI is shielded (Supra cable) it still emits huge amount of EMI - really strange.
I don’t think we need to create dedicated web site/blog - maybe we can just create some (I2S) Digital Transport section here on PSA forum in the DYI forum part - what do you think?
BTW for EMI/RFI detection I am using “Elektrosluch” device made by friend Jonas Gruska who is designing building and selling this nice piece of HW: https://lom-label.myshopify.com/collections/elektrosluch-accessories/products/elektrosluch-3?variant=4542168268832 - I am using it to discover EMI emitting devices/cables and sometimes borrowing it to kids to play with it too :))
Héhé, when i added the copper band to ground together both HDMI module and the aluminum box, I was a bit disapointed by the SQ result. However this came in same time with other small modifications, so I thought it was may be not related to the ground modification. I’ll try to remove this link.
Did you ever measured, with the interesting elektroluch tool you mentionned, an EMI reduction on a cable shielded with such tape usually liked by electri guitar player (see here: EMI tape) ?
It’s what I used on the I2S wires between Hecate and HDMI module.
I’m wondering that because, basically, I’d like to know the effect to ground or not the shield around a cable. Is a grounded coper shield more or less efficient than a Not grounded copper shield, for example ?
I’ve been trying to get a Sparky I2S Roon streamer running for the past few months and tonight had the first success!
The chain is Sparky SBC (with music from an attached USB drive or through Roon over the network) > Ian Canadas McFifo > McDualXO isolator and reclocking boards > Audio gd I2S HDMI module > to the I2s input on my PS Junior DAC.
After much trial and error I’ve got a basic set up with music playing this evening. What a relief after many weeks of multiple attempts. Sounds very good so far, and surprisingly clean and spacious but its early days yet and needs a few days burn in before commenting fully…
I’m currently running Volumio on the Sparky. Now I can start experimenting to get Dietpi running. Apart from sorting out multiple connections I kept trying various driver selections in Dietpi, Ropieee & Picoreplayer with no success. Then in Volumio instead of the I2S DAC options I tried HDMI output (see pic) and that worked, so I realised I’ve been following the wrong assumption about which outputs should work. I will detail the chain when I have a chance to experiment some more. Just enjoying the payoff with the sound opening up significantly after an hour of playing …
2 Likes
For anyone interested in my Sparky I2S Roon Streamer I managed to work out the problems I have been having in setting it all up as it is a complex chain and it has been running continuously for a few days. Now I will concentrate on optimising the cables, EMI shielding etc and housing it all in a metal box…
My new streamer chain is: Sparky Roon end point (network connected running customised Dietpi software with Roon bridge on a 4 GB micro card) I2S outputs connected to Ian Canadas McFifo Isolator board, then connected to his McDualXO reclocking board with upgraded Crystek CCHD-957-25-45.1584 & CCHD-957-25-49.152 clocks, then to an Audio gd HDMI module to I2S input on my PS Audio Junior DAC. Everything is running superbly and sound is stunning.
I have Dietpi running well, which was the goal and even MQA from Tidal plays without any downsampling.
The SQ now beats my previous best - the Bluewave USB to SPDIF chain. The difference is subtle, but distinctly sweeter with all the detail, air and with tight muscular bass. Voices are very natural and lovely sounding, everything is harmonious and united yet full of detail and space.
If anyone is interested I can detail the build, as its worth pursuing this route if you want to make an excellent Roon streamer to use the I2S input to your DAC.
1 Like
Hi, for those interested by the NanoPI SBC combined with an Armature Hecate (USB to I2S output) and an I2S to LVDS I2S/HDMI (in my case on the NanoPat, an AudioGD module HDMI output), I’ve been able to rebuild the Armbian Kernel in order to support NativeDSD in all latest releases of DietPI.
In a nutshell, here the procedure on a NanoPI with DietPI:
- install all the compilation stuff to rebuild under armbian (gcc, libs, …)
- download the linux kernel sources 4.4.18 in a folder
- modify the linux module “snd-usb-audio” in (file sound/usb/quirks.c) as indicated here: https://github.com/friendlyarm/linux-4.x.y/blob/nanopi-v4.1.y/sound/usb/quirks.c
- compile the kernel (only compilation, “make zimage” is sufficient, “deb-pkg” did not work for me)
- compile and install linux modules (where resides quirks.c) with “make modules modules_install”
I hope to forget nothing, but that’s all. No Alsa or whatever software to patch/compile in addition. The build duration took several hours. A cross-compilation is surely preferable, but here is what I did.
I can read flawlessly my DSD files in Native mode on the NanoPat. Roon recognizes the Native support, great It shows a full green list of supported format, up to DSD512. I downsized the support up to DSD128 in respect to what the PSAudio DirectStream DAC is able to go.
Ive installed this kernel (and module) since 2 month now, and had no need to rebuild the kernel through the several releases of DietPI (from DietPI 6.0 up to the latest 6.7).
The patched modules are dedicated to the Kernel 4.4.18, so I don’t think you can easily use the modules 4.4.18 with another Kernel. Thus if an upgrade of DietPI is provided with a more recent Kernel, we should have to redo this process with the new kernel.
It would be ideal to add this patch in the Linux Kernel’s Mainline (the one provided by the OpenSource community) but I don’t know for the moment how to do that. As you can see, it’s a pity to not have it included in mainline, since the patch is very light.
2 Likes
Nice! Thanks for the update @patr
Not sure if it has been mentioned, but the Pink Faun I2S card will output I2S for PS audio (they have MCH as well). it can be installed in any server or as part of a turn key Pink Faun server.
I believe drivers for this card are Windows only.
They sell their machines running linux, so you can use the card with linux based platform.