IanCanada's Latest RPi GB Goodies Impressions... and your tweaks, mods and hints...

I think I missed it - what does the new ShieldPi V2.0 do?

The ShieldPi is basically a board with a ground plane, to shield the noisy boards from the DAC and output hat.

V2.0 adds a cutout to be able to remove the oscillators from the fifopi more easily, if I understood some previous information I found on the subject.

Attached is a relatively recent picture of my stack, with the original ShieldPi between the fifopi and dac.

I think it does remove some ultrasonic harshness, the stuff you can't really hear but can make a system fatiguing. Or maybe its all in my mind lol.

I'm not using a pi anymore, little board in front is a usb to i2s converter which is wired into the dirty connector of the fifopi.
Battery on left is for the converter, ultracaps on the right is to generate 5V for the fifopi.

Ultracaps in the rear generate clean 3.3 for the fifopi and 3.3 for the dac.
I plan to make a couple more ultracap 3.3v supplies for the dac. I also want to try adding lifepo4 batteries in front of the ultracaps, and see if it makes any difference.

Also attempting a diy version of an i2s terminator. Will see how that works.
 

Attachments

  • IMG_4061.jpg
    IMG_4061.jpg
    770.6 KB · Views: 809
@zgtc

1. will it be possible to use RPi pins to select the source (not just auto if present in S/PDIF or USB channels)?

It is possible to control the ReceiverPi selection by GPIO pins, but I have no time to write the code. If you can do it, I'll let you know how.

2. how many GPIO free pins will be available in the RPi?

There are many free GPIO PINs on RPi, but FifoPi will need only three of them.


You can also use the auto selection which is the default.

Regards,
Ian
 
It is possible to control the ReceiverPi selection by GPIO pins, but I have no time to write the code. If you can do it, I'll let you know how.
Pretty cool if selection can (also) be made programmatically. I can do some python script, I guess we'll need some info about the expected API or internal address of the source selection.

There are many free GPIO PINs on RPi, but FifoPi will need only three of them.
OK maybe I should've asked the other way around then. To be more specific, which pins exactly will the ReceiverPi use?

Thank you again
 
The ShieldPi is basically a board with a ground plane, to shield the noisy boards from the DAC and output hat.

V2.0 adds a cutout to be able to remove the oscillators from the fifopi more easily, if I understood some previous information I found on the subject.

Attached is a relatively recent picture of my stack, with the original ShieldPi between the fifopi and dac.

I think it does remove some ultrasonic harshness, the stuff you can't really hear but can make a system fatiguing. Or maybe its all in my mind lol.

I'm not using a pi anymore, little board in front is a usb to i2s converter which is wired into the dirty connector of the fifopi.
Battery on left is for the converter, ultracaps on the right is to generate 5V for the fifopi.

Ultracaps in the rear generate clean 3.3 for the fifopi and 3.3 for the dac.
I plan to make a couple more ultracap 3.3v supplies for the dac. I also want to try adding lifepo4 batteries in front of the ultracaps, and see if it makes any difference.

Also attempting a diy version of an i2s terminator. Will see how that works.

Thanks randytsuch, your answers are correct,

More information of ShieldPi V2 was updated here:
https://www.diyaudio.com/forums/dig...mate-weapon-fight-jitter-510.html#post5956035


ShieldPiV2_3
by Ian, on Flickr

Have a good weekend.
Ian
 
Hi.

I like the idea of a receiver HAT.

However. IMO SPDIF/Toslink and I think even USB audio I consider a dying art.

What would really be nice is to have an autosensing HD Audio BT
(APT-X HD/LDAC/AAC) receiver HAT.
E.g. iFi just launched a rather entry level Sabre based wireless receiver at a reasonable pricetag. I could imagine to have a HAT with just the receiver part.

Honestly. 80% of the music I listen to nowadays, I stream over BT. Beside that the whole family also uses mainly their mobile devices and could easily stream their stuff on the main stereo.

The RPI BT stack I do not consider a viable solution.

An autosensing HQ BT HAT is what I'm really looking for.

Enjoy.
 
BT, really!?

I guess it is a very personal thing, which audio is anyways...

There's nothing personal.

It's all digital. And BT is up2 96kHz.
What matters is a proper implementation. And that's the actual challenge in HQ audio, as we all know. If you get that managed there'll be no issue.
Many audio solutions, even low cost audio solutions -- have these challenges pretty much under control nowadays.
Meanwhile every toast out there knows the rough recipe how to get a quality device done. Of course doing it is another story. :p

And then - I hear u - ""It's 96 only"" :cannotbe: .
To be honest. Who cares about the 0.1% or less who scream for DSD ? ;)

Being at that stage where the actual HQ audio equipment become commodity products, the focus will turn very much on reducing complexity and increasing usability of these products/solutions.
And. Yep. That's where I see myself since quite a while.
Using HD BT in conjunction with Wifi streaming (or similar) I consider the currently most convenient least complex approach out there.
Think about it. The whole audiophile cable industry will loose its purpose. :D

I for myself am just lacking the BT part on my wireless RPI/HAT approach.

Talking about convenience. My DIY audio system is 100% remote controllable nowadays - even the power sockets.
I wouldn't accept anything that's to be done manually on any device in the chain anymore.

Obviously the whole BT/wireless audio subject has not yet arrived in the DIY arena.

Enjoy.


PS: And the absolute endgame I'd consider a dual-mono BT/wireless solution, to be able to finally get rid of my speaker cables. ;)
 
Last edited:
Run DSD true sync mode with ES9038Q2M dual mono DAC, I make it!

Hi guys,

I'm very happy with the sound quality of the true sync mode, so I posted my experience in this post a month ago,
https://www.diyaudio.com/forums/pc-...essions-tweaks-mods-hints-89.html#post5920007

But the only problem I had was that the true sync mode doesn't work with DSD. Now, the problem is fixed. I know the reason and have the solution.

Some community members told me that they can run DSD at true sync mode with DSD bandwidth 0 and DPLL stopped. But I tried many times without success. The other day Vin send my a picture of his system running DSD at this mode. I was wondering why.

One day, I occasionally up-sampling the DSD64 to DSD128 for my Roon endpoint, I found I had no problem with DSD128 music at true sync mode(45.1584 MCLK). I suspect it must has business with MCLK frequencies.

So, I changed my XO frequency to 22.5792MHz from 45.1584 or 90.2168MHz, and set DSD DPLL to 0 with DPLL stopped. OSF can also be set bypassed. I make it! Both DSD64 and DSD128 works perfectly at true sync mode. With Crystek CCHD957, my ES9038Q2M dual mono DAC sounds amazing. My DSD music never sounds as nature and analog as this. Roon, Volumio and all other software do the same. I have a LINN sound tracks in SACD iso format. I played the SACD image file by Foobar2000 (with DSD plugin) in native DSD mode through my Amanero USB streamer (also with ReceiverPi). The sound style was very close to a Vinyl record but just without the noise (with Bisesik transformer I/V).

So, the solution is simple: use 22.5792MHz XO for DSD64 and DSD128, or up-sampling music to DSD128 to use 45.1584MHz or DSD256 for 90.2168MHz.

I believe the sound quality still has room to improve if using better clock. Just hope I had a 22.5792MHz Pulsar OCXO. Too bad they were discontinued.

Ian
 

Attachments

  • TrueSyncDSD1.jpg
    TrueSyncDSD1.jpg
    610 KB · Views: 737
  • TrueSyncDSD2.jpg
    TrueSyncDSD2.jpg
    439.1 KB · Views: 735
  • TrueSyncDSD3.jpg
    TrueSyncDSD3.jpg
    439.7 KB · Views: 704
  • TrueSyncDSD4.jpg
    TrueSyncDSD4.jpg
    398.3 KB · Views: 695
Last edited:
D

Deleted member 537459

My sistem work in true sync mode with dsd64 and NS 11.2896 clock. My problem is with Ian's 9039q2mdm, sometimes the dac loose the signal when i switch mqa to pcm or after pause i play and no work. I try 9038pro, is 3 weeks eun with no problem. No bump no loose signal nothing os all perfect. I don't now why. Ian i send the neutrino clock sorry but i try some things. This week i send you.
I feed my raspberry with linear supply with ultra low noise regulator, it's a big improvment!!
 
Member
Joined 2018
Paid Member
Wiring optical spdif to Ian Dual dac

I have this optical spdif receiver

192K Optical SPDIF receiver - DIYINHK

And would like some help in wiring it to the dual mono dac. The dac has vcc, gnd and spdif input pads. The receiver has 4 terminals .

Any how do I listen to this input.? Just by turning off Rpi to disable i2s stream. Or just not to stream through Voljmio etc..?

Thanks in advance
 
Last edited:
Thanks randytsuch, your answers are correct,

More information of ShieldPi V2 was updated here:
https://www.diyaudio.com/forums/dig...mate-weapon-fight-jitter-510.html#post5956035


ShieldPiV2_3
by Ian, on Flickr

Have a good weekend.
Ian

The ShieldPi should be designed with a grounding terminal to allow the user to externally connect to the ground, such as a separate grounding box. The grounding box can be replaced by a high quality speaker cable that is mainly made of copper.
 
Last edited:
OSF Bypass with True Sync

I’m using 9038Q2MPi Dual Mono with FifoPI and ESSController with True Sync mode (No Bandwith 0). My clocks are NZ2520SDA 22.5792 and 24.576. Works well and while monitoring DPLL, it shows 0x00000000.
Should OSF Bypass work for me, when listening to 44.1KHz music sources? Selecting OSB Bypass works (no change in music quality though), but when playing next track/playlist, it stays silent. I'm using Volumio.
Any thoughts?