Asynchronous I2S FIFO project, an ultimate weapon to fight the jitter

Jump to Latest
#6,201
dddac said:
The DDDAC was designed with the WaveIO as source and there the I2S clock never stops (like you suggest with the Amanero)
Click to expand...

dddac said:
So when the FiFoPi stops the I2S signal at full breaks, the DAC would not mute
Or can you program FiFoPi so, that the WCK runs runs for another 2k or so?

May be another solution could be (just wildly thinking) to have the audio player have a short mute between tracks if that is possible?
Click to expand...

This makes sense and it would explain why I have no issue with RPI -> WaveIO -> DDDAC. But please note, that I have also no clicks when using RPI directly. Means RPI -> DDDAC works OK! To be honest, I have only tested for some minutes without FifoPi - switched between different tracks without a click. Then installed FifoPi back in my chain and click with first track playback. Mh, should I do another try without the FifoPi to proof the clock stop thing?

@Eduard: Thank you for the information. I have tried this choke setup a while ago. I think I lost some punch with it and then switched back to the simple serial setup. But this was at a time where my DDDAC setup was not that modded and I will give it another try.
 
#6,202
Hello,
Per Lundahl himself told me that it should be better but you will have to try.
I started with choke input with the ll2733 and now i am using the ll2771. I have never tried the normal connection but i never missed some punch. Maybe be cause i always used more mH. First 544mH and now 3000mH. A famous technician in my country said you should only use this technique for the input choke but i used it for all the chokes right away.
In a few weeks times i will also replace the 700mH? By a ll2771 with reduced airgap so around 6000mH for the choke input supply of the wave io board.
Greetings,Eduard
 
#6,204
Hello,
There is no saturation because a two board DDDAC will draw around 500 mA. These chokes are rated for 1,5A
This is choke input power supply.That is the reason for the voltage drop. Very old school but when done properly works GREAT.
Greetings, Eduard
 
#6,206
michl2604 said:
This makes sense and it would explain why I have no issue with RPI -> WaveIO -> DDDAC. But please note, that I have also no clicks when using RPI directly. Means RPI -> DDDAC works OK! To be honest, I have only tested for some minutes without FifoPi - switched between different tracks without a click. Then installed FifoPi back in my chain and click with first track playback. Mh, should I do another try without the FifoPi to proof the clock stop thing?

@Eduard: Thank you for the information. I have tried this choke setup a while ago. I think I lost some punch with it and then switched back to the simple serial setup. But this was at a time where my DDDAC setup was not that modded and I will give it another try.
Click to expand...

@michl2604

I think the best solution for your would be the BridgePi for now.

You just need to install the BridgePi between RPi and FifoPi together with an Amanero Combo384 (You will not need the TransportPi which is in the third picture). All of the problem will be solved.


BridegPiUSBstreamer by Ian, on Flickr


InsatllUsbStreamer by Ian, on Flickr


AdvancedDSDDAC by Ian, on Flickr

Regards,
Ian
 
#6,207
Yes Ian, this would be a solution, thank you.

Some weeks ago I have also tested WaveIO (USB - I2S Interface) together with Fifo Pi and with this setup there were also no clicks.
However, soundwise I prefered the Fifo Pi only setup!?? Don't know why. In theory it should sound allways the same behind Fifo Pi, isn't ?

Is there a difference soundwise between using BridgePi / Anamero / FifoPi combo and FifoPi only?

A good finding from this thread for me: my fifo pi copy is not defective and it makes no sense for me to send it back for exchange. :up:
 
#6,208
@michl2604

All XMOS USB solutions have 2ns system jitter. You can check my previous post (long time ago) for the real measurement results. I have both but Combe384 sounds better for me because it has dedicated audio clocks.

DDDAC takes 32bit I2S (64Fs) format only. And a USB interface also runs at 64Fs. So the sound quality shouldn't be a difference. Based on my recent experiences, Com384 has better clarity than RPi GPIO. It could be caused by different EMI noise level. But it's just a subjective feelings.

Good weekend.
Ian
 
#6,212
iancanada said:
@michl2604

All XMOS USB solutions have 2ns system jitter. You can check my previous post (long time ago) for the real measurement results. I have both but Combe384 sounds better for me because it has dedicated audio clocks.

DDDAC takes 32bit I2S (64Fs) format only. And a USB interface also runs at 64Fs. So the sound quality shouldn't be a difference. Based on my recent experiences, Com384 has better clarity than RPi GPIO. It could be caused by different EMI noise level. But it's just a subjective feelings.

Good weekend.
Ian
Click to expand...

Thank you for the information! :up:
Wish you a good weekend, too! 🙂
 
#6,217
#6,219
I am looking to get some insight from other McFIFO / McDualXO users who are using a Crystek 957.

My setup is a miniDSP miniSHARC -> McFIFO -> McDualXO. I have come across an odd issue when using a 24.576 MHz Crystek 957 in that it will only work if I remove the E/D pin 1.

I've observed this across two different miniSHARCs, two different McFIFO / McDualXOs, many different Crystek 957s (on both Ian's specific 957 adapter as well as his generic adapter). In all cases the McDualXO will select the correct oscillator, I get MCLK and SCLK signals from the McDualXO but no LRCLK or I2S data. I have not observed a similar issue on other oscillators with an E/D pin such as the NDK SDA and the Crystek C3391.

At the end of the day removing the pin works fine but I would like to know if anyone else has experienced a similar issue or if anyone can think of a reason as to why it is occurring.

Thanks,
Michael
 
You must log in or register to reply here.
Top Bottom