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

I have re-read my post #920 and seems it can be occur wrong meaning regarding PCM vs DSD. I meant I have too less music in DSD to compare with tons of PCMs I have. The best musical material I have in terms of natural live-like sounding quality in my collection is Opus3 Showcase.
Right now I have tested very briefly the difference between OSF and nonOSF on "House of the Rising Sun" and "Leaves" (1-st and 2-nd tracks in Opus3 Showcase #3). Guys, it is noticable at once - with noOSF (true sync) the sound is more precise, instruments and voice are located more accurate in space (better instrument separation), sound is more delicate. In OSF mode the sound images are fatter and blurred in space, worse in total. It is my wife's words actually after a minute of listening, I am agree with she (as usual anyway :D )
 
Last edited:
Thx. You pretty much confirmed what I've been expecting all along. :D
I simply didn't know that the Ian's controller would allow OSF-B.
I really don't know why this wouldn't pop up earlier. Such a "low hanging fruit". ;)

I had similar effects with the 51xx DAC filters - bypassing these at 352k8/384.
If you'd followed the Soekris DAC filter brewing thread you'd also have seen what impact these filters can have.

And then there were even people liking the 9038 minimum phase filter best. A filter that starts dropping of short after 10kHz.

Bottom line.

True Sync + OSF-B seems the way to go with this DAC. Good news.


The only issue ( OK. OK. Not such a big issue) with Ians DAC - if I recall it correctly - is that it's not slaving the RPI as e.g. the Katana does.
Perhaps somebody can confirm that.
FifoPi wouldn't support a DAC as I2S master, if I'm not mistaken.



BTW. What clock frequencies are required to run True Sync?
 
Last edited:
1. Even with reclocker the pi keeps delivering really poor (reliable?) I2S in RPI I2S master mode
2. No reclocker is perfect, usually small flaws get added by the reclocker itself

If you are able to cope with that poor RPI I2S performance,
why not avoiding it from the beginning?

It requires a Linux driver! You'd need to tell the Pi what's going on there.
And if you want to run it this way you'd need an on-dac MCU that gets controlled by the RPI driver.
Not sure if Ian could make his MCU that way that it would run similar to e.g. the Allo Katana.

A Linux driver is a NoGo for Ian. He built a standalone unit. I guess that's why he got stuck at that point.


However.

We're talking about micro-impact I'd say.
Once more. It's always about finding the better compromise. ;)
 
Last edited:
why not avoiding it from the beginning?
Depends of answer to the question - what is the beginning in terms of digital audio? (Have you tried Ian's Fifopi with RPi BTW?)
I prefer not to dig so deep but just to shift a bit this the beginning. It is simplier for me to compare Ian's FIFO with the beginning of the digital signal path - say let it be the music storage place but with one exception - music is uploaded more often to it. Again - the main rule in my mind - it should be the bitperfect playback (no matter what jitter was before or during putting the data to the fifo memory - the main is to care of the correct bit sequence before putting it to the fifo memory). But the really important is what happens later (after fifo, at it's right\clean side). It is simplier for me to put things on shelves on this manner rather than trying to eliminate all the gaps before fifopi. Have I missed some important things? What is the memory (time) size of Ian's Fifo for DSD btw?..
 
Last edited:
1. Even with reclocker the pi keeps delivering really poor (reliable?) I2S in RPI I2S master mode
2. No reclocker is perfect, usually small flaws get added by the reclocker itself
I have a hard time agreeing with point 1. Perhaps I am misunderstanding..

Ian's FIFO reads data into a buffer, and then creates the I2S stream based on it's on board clock. Aren't we listening to FIFO, not the Rpi??

The resulting sound is dependent on the FIFO and it's clock. The latency or clocks on the Pi should have no more bearing on the sound than the latency of the HDD filling the buffer in the Pi. Take it one step further.. There is a latency collecting the tracks from a CD or from the net onto the HDD. The time it takes to go to the store and buy a CD and rip it to the hard drive does not affect the sound. It is the accuracy of the timed signal created by the FIFO reading from its buffer that counts.

WRT your second point, i agree that no clocking system is perfect. The impact on the sound of derived from the Rpi, the network, and the storage medium all have to do with the effective limits of the isolation on the FIFO IMHO. So I believe if you are suggesting that timing errors on the FIFO are additive to the timing errors on the upstream transport, I think you are mistaken. No offense meant, just attempting to sharpen my understanding.
 
1. It's well known that reclocker in general are not flawless.
Of course they are cleaning up the mess big time. But do not expect
a perfect I2S performance.
2. From all the discussions and tweak proposals around Ians FifoPi it should
also be widely known that this device is not flawless.
Not sure how many times I read "wow - what a step forward" after the
next greatest clock or power supply enhancement.
3. Unfortunately I've never seen any measurements related to the FifoPi.
That's why it remains a kind of black hole to me.

On the other side.

Allo with the Allo Boss, Digione or Katana simply eliminates all this by putting the audio device in I2S master mode. Allo claims performances in the range of 500 femto seconds jitter.
Allo also had a reclocker called Kali in the early days. It was and still is good.
If you can achieve better performances with less effort you simply do it.

Less can be more - if done right.


BUT.

Allo also has issues. E.g. Their solutions are much less flexible. Allo also lacks features here and there e.g. OSF-B and I don't like their isolator approach.
And then you also need to add highly complex PS solutions for best performance.

Once more. At one point we'll always run into a compromise.
 
"wow - what a step forward" after the
next greatest clock or power supply enhancement.
In my mind it is still belongs to the right\clean side of the Fifopi - and there is no any big surprises for me that it should give effect. It will be strange if viceversa would not have impact compared to the stock version. But for me it will be really strange if there will be some impact if to shift the RPI from master to slave mode with fifopi as the next receiver board (without any other modifications of fifopi and its environment).
OK. There can still be some undescribly changes in sound, I agree. I would like to check this somehow... How do you think - should it change the situation with (undesireble) I2S from RPI's GPIO if I will use jlsounds i2soverusb with RPI which I want to try anyway (to avoid DSD128 limitation)?
 
1. It's well known that reclocker in general are not flawless.
Of course they are cleaning up the mess big time. But do not expect
a perfect I2S performance.
2. From all the discussions and tweak proposals around Ians FifoPi it should
also be widely known that this device is not flawless.
Not sure how many times I read "wow - what a step forward" after the
next greatest clock or power supply enhancement.
3. Unfortunately I've never seen any measurements related to the FifoPi.
That's why it remains a kind of black hole to me.

Once more. At one point we'll always run into a compromise.

I struggle to understand what flaws you cite. The purpose of the FIFO is 3 fold IMHO.
1. Bit perfect i2S stream. Has been confirmed.
2. A low jitter/phase noise. Depends by design on the clock. The measure of the FIFO would be to what extent the clock performance is reflected in the sound quality. The WOW what an improvement observations confirm its merit in this regard.
3. Isolation of noise from the upstream components such as the LAN, the Rpi or the storage system. Here it seems there is room for improvement. As with all devices, there is a price point to hit and I think it has done pretty well. Anyone looking for additional isolation can in fact add a downstream isolator. Ian even gave away PCB's at one point. I keep mine available for a future experiment.

The fact that an excellent power supply can improve the sound is similar to the user supplied clock. It is a design feature not a limitation. Those who want a decent HiFi can plug in a cast off cheap wall wort and get sound (with the supplied disposable clocks). As with all audio, better power will reward better sound. As a DIY guy, I like the fact I can choose the level of mania to invest in power/sound balance.

If you want plug and play, that is what consumer audio is for. By a Mini Mac and a Benchmark DAC and you'll get a predictable sound without worrying about clocks or PS. They have made those choices and baked it into the price. But then if you want an improvement you have to discard the Benchmark and buy an Esoteric. I agree with your point about compromise.
I prefer the flexible upgrade path provided by FIFOPi.
 
Member
Joined 2018
Paid Member
Good evening.

Today I managed to piece together my stack. I got the boards from Pistollero via the swap meet. I dont have a fifo, just an isolator, dual mono dac and STD IV.

The controller is doing the scrolling dots thing and nothing else. I have no lock LEDs and no sound.

Moode is my platform. Before this I used isolator and Dac+ Pro which is a master mode dac. I have reset the jumpers on the isolator to slave.

Have tried generic 1 i2s , generic 2, hifiberry dac+ and also some other ESS based options within moode but nothing helps.

Any suggestions welcome please.


Edit......had a thought. The dac came with a ufl in J5 for MCLK. Isn't connected to anything obviously. I didnt wantnto force it off so left it on. Is that the culprit.?
 
Last edited:
Has anyone tried a Raspberry Pi 4 yet ?

Having looked at the thermal issues with the Pi4, I think putting any sort of hat on top is a bad idea.


Enclosed in Pi Case Pi 3 B+ Pi 4 Pi 4 (4K)
CPU Temperature (°C) 53 78 77
CPU Temp. over ambient (°C) 27 49 55
Power Consumption (W) 2.5 3.6 3.9

Board in open Air Pi 3 B+ Pi 4 Pi 4 (4K)
CPU Temperature (°C) 48 62 62
CPU Temp. over ambient (°C) 22 36 40

Raspberry Pi 4 Hot new release – Too hot to use enclosed - MartinRowan

So first off I shall split my stack and put the Pi in a metal enclosure, though as I also have a 1TB SSD underneath Im thinking it through.

2grctmY7D2QK1_PyA4kPn6CREN5juGK3t73dLX98hHvjHdfPNzHzFLUqu6zRMUWCzRIUc227qOu6CIuiBiFNt1cq_xHJiym_XzHh8hjdBDwP1h-DBfzGvk_sVyW8krQ82R6c6D9apPmtPCy2_3oTRaE-YXbroA1FrgBt5znpiyeEHczEeLWLCBWKgH25futQCmQ9chvjk84vKig2trD3pNFn8kWCAQS00rRL8i9Cr9zn-iPDL8nL3Uzwp0KrvgIRvPXaQnh_N_jov8aiUgo_4jNDUVhUxgSBw4Z2oMovrsbryoyRg7Sq6Tf7VgRlNzdpE_J0khvQ2ftTIyUYrPOX1X5Fp2PcPXV5jwgC_TAqbejxlXG1m5yruZ03dCzoqz4Pgwf8ZPyN22Z5B_VcXRCVrpalalnFrhsgXzokfybU0MKkvkSrDHjaqzv10sErp5v4DDLO8nNalDgz_QVBkyLFo7aoDJe8Eh0O3P99sdh052Xi1TIVNJl1OK5JXVCmKDJ4c1vxah28tU6X_Ve5vtG0pQ9BpCReDnqVcoehqY-NthelEWDPV6FkHHGv6fAerYcWJ3g5HjJkOKMjmiXD6X4XAppP5YXoa894tl4JM84avCxfcza569jrzW4C7eupooMMWgBnV9BXX4H_uwZ55yq_0yP32Wnbr7xUGc3EUvA7d-b1tV2VZb8hVXVouvXNfoHO_-ZiqtC2ZJbh1dgoIAAw5STeRrkCWX9Kztb0-776XMpMw6Q=w1237-h695-no


My long term aim is to incorporate Mo0de into the SSD and have a Pi 4 all on USB 3.

Does anyone know what the maximum current available from the 5V J8 on Ians LifeP04 board is ?

Is it 2A the same as the USB J7.
 
Member
Joined 2018
Paid Member
^^Looks good Misterdog.

I am way behind you guys but I am enjoying my currently stock dac stack....and no fifo. I am asynchronous for now.

A few questions if I may.

1. I get pops when selecting between tracks or radio stations on moode. Any fix?

2. As I have no fifo....could I use my Hifiberry dac+pro to send an MCLK to my isolator and so to my Ian dual mono and use it in master mode?

Thankyou