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

[iancanada]

Ian,

just dump the endless discussion on phase / jitter - your FiFoPi sounds very nice and that is what counts.

on the subject above, yes, that would give us some very nice view and perspective on things. Looking forward to this.

just saying, as you go, please measure jitter for:

clock from PI
clock From J2
clock from U/FL

Could you do both MCK AND please also SCK !! (this does the conversion in many (or most) DAC chips...

thanks,
Doede

That's no problem. Will do it.
Why do you use J2? It's non-isolated and has higher jitter level.

Regards,
Ian

 

[iancanada]

Thanks Ian.
I don't have the dual XO clock board. Is it the case the Si570 won't work wth the SPDIF board, even just to try it out?

Si570 clock board was discontinued. You can try low frequency settings to see if it good. The old S/PDIF board only takes 22/25 MHz MCLK.

But you can use the new TransportPi, it works with higher frequency.

Regards,
Ian

 

[iancanada]

FifoPi test: (2) Watch RPi I2S jitter directly from SCK waveform before FifoPi

Let's continue the FifoPi test.

Jitter measurement sometimes is pretty hard to understand. So just let me make things easy.

Raspberry Pi I2S jitter before FifoPi is so big that we can even watch it directly from waveform with normal digital scope (no need the jitter package). Here is the test result under the same test condition as test (1)
https://www.diyaudio.com/forums/dig...mate-weapon-fight-jitter-533.html#post6284897

RapberryPi 4 B
Volumio play 44.1KHz 16bit music
Pick up SCK signal from RPi GPIO

LC584AXL (jitter package disabled)
Sampling 8GS/s @ input bandwidth 1GHz
Trigger at positive edge and watch the jitter at the following positive edge

swps 10253 times
watch: cycle-cycle period jitter

Testing results
Obviously, we can see both random jitter and domestic jitter directly from the RPi SCK waveform. The random jitter (each group) is around 300ps RMS, it should be the jitter of the internal VCO. The domestic jitter (the two groups) is separated 1200ps in between, looks like that RaspberryPi internal DPLL jumps between two factors for the audio clock. From this waveform we can roughly know how a RaspberryPi generates the audio clock.I don't think an audiophile can live with digital audio signals of this quality.
This measurement is very easy to implement. Anybody with a 200MHz or higher digital scope can do the same test.


RPiSCK44.1K16bitWaveform by Ian, on Flickr

More analyzing

By comparing the SCK waveform and previous jitter measurement result, we can see the two testing results match pretty well.
The two groups of the waveform are corresponding to the two Gaussian distributions in the jitter testing result.
Jitter testing results use a histogram to describe the jitter behavior is exactly the same as what we saw from the waveform.

(Jitter measurement result)

RPiSCK44.1K16bitold by Ian, on Flickr


Ian

 

[photochum1]

I use Volumio with Roon endpoint plug-in.
And I access my local music lib on my UPnP DLNA server through Volumio.
I can enjoy both. I'm so happy with my setup.
Foobar2000 DLNA server is so far the best I've been used. Sound quality is amazing.

Regards,
Ian

Dear Ian,

Could you share a bit more on how to use volumio with Roon Endpoint Plug-in? or is there any tutorial or link available on the net for me to look at?

And in terms of compability & support do you recommend Volumio with Roon Endpoint Plug-in vs readily use Ropieee?

Many thanks

 

[photochum1]

Some diyAudio members told me that they had problem playing native DSD music on Topping D90 DAC through HDMI IIS input. PCM music has no any problem.

I think the reason could be that the D90 can not detect DSD signal when native DSD was sent through HDMI IIS. So I did some research and found that it's possible to switch D90 into DSD mode manually by setting pin15 of HDMI signal to high.

On the my TransportPi and HdmiPi transmitter boards, I reserved a input "signal" that can set pin15 of HDMI high or low. They are:
J9 for TransportPi
J8 for HDMIPi transmitter

So, if you are using my TransportPi or HdmiPi for D90, the current solution is to connect a switch between the on-board 3.3V output and the "signal" pin. Manually switch it on when you play native DSD over the HDMI IIS. And switch it back to off when you play PCM.

Down the road, maybe I'll consider providing an automatic PCM/DSD switch solution.

Please let me know for any update.
Ian

Dear Ian,

Wow nice, really appreciate for the good support
Will this work for Topping D70 also?

Many thanks

 

[photochum1]

Luchoh gave me a very good information about RPi DSD128/PCM384 KHz solution and I confirmed it works!

In the Volumio, when you select Audiophonics I-Sabre ES9028Q2M as DAC model, RPi can play up to DSD128 (through DoP) and PCM 384KHz even without an ESS controller (Though you can still use it as real time stream monitor).I configured as this setup it works great!

That's a really good news.

@ Luchoh Thank you so much!

https://flic.kr/p/2jdwtV6
384KHzSettings.PNG by Ian, on Flickr

Have a good weekend.

Ian

Dear Ian & Guys,

First of all, thank you for sharing all the knowledge in this forum, i've been browsing the Ian's threads for quite sometimes for my 1st RPi projects

Here is quick update on my Rpi project of I2S Digital Streamer via HDMI with Ian's products:

My setup are as follows:
RPi 4 + FIFOPI Q2 + Transport PI > I2S Output via HDMI > DAC Topping D70 using Ropieee as Roon Endpoint

After trial & error for sometimes, finally I manage to stream seamlessly PCM 16/44 to 32/384 even DSD 64/128/256 via DoP from the stack to my DAC and finally to my amplififer

As suggested by Ian, I select Audiophonics I-Sabre ES90X8Q2M as Audio HAT in Ropieee, but at first trial I do not get any sound. Then I noticed that I can play tracks and get sound on tracks with PCM rate of >=96 khz but not below, then I notice that there is S1 switch no. 2 about forcing 16 bit to 32bit. I set the S1 switch no.2 to ON and it can play 16/44 now

Have not tried the hard switch for activate Native DSD for Topping as suggested by Ian, will try it this weekend while also working on replacing the standard clock with Crystek clock

Regards

 

[marcus1]

EthernetPi?

Hi Ian

I know that some use the RPi and associated equipment as an ethernet to I2S converter but what about an using it the other way: an I2S to ethernet converter?

I have an sd card player that outputs I2S and would like to input it into my Buffalo switch/LAN.
Is a EthernetPi design on the cards using a RPi, FIFOPi etc? If it's possible, I'm sure something like this would be very popular .

 

[JCMcNeil]

Right placement of Fifo/reclocking in multi-channel chain with MiniSharc?

I have a question about reclocking/Fifo/buffering I'd like help with. To set the stage:

I have a multichannel multibit Dac + MiniSharc project in the works (which may merit it's own thread soon, perhaps).

I'm in the process of experimenting with DIY builds of different dac chips...

Have built a few around the TDA1387 and also have some AD1865 and TDA1541a chips on hand to play with. The TDA1387 is very easy to implement so version 1.0 is likely to center on that.

Currently, the chain is:

Raspberry Pi 4 (4GB) running Volumio ->
Ian Canada FifoPi Q2 Ultimate ->
MiniSharc in Slave mode ->
Multibit DIY Dac d'jour (currently TDA1387 based) ->
DIY Passive IV/ filter (testing various filter circuits) ->
PGA-8CH 8-channel volume/gain ->
tube amps for tweeters and mids, SS for woofers, D-class servo for subs ->
passive crossover-ectomied NHT Classic 3's & 12" Rythmik Servo Subs

I understand the MiniSharc's DSP likely adds a lot of jitter.

What's the best solution to reclock, reduce jitter, buffer/Fifo, etc for optimum sound quality?

If I add Ian's McFifo and McDual after the MiniSharc, does that render the FifoPi Q2U redundant? Or?

If I roll my own solution as a learning experiment, what's the best direction to go in?

Are there ways to clean up jitter after the MiniSharc and continue to utilize the AccuSilicon clock in the FifoPi Q2U?

Any other ideas or things I should do differently?

Thanks!

 

[iancanada]

@ JCMcNeil

For multi-channels application, McFifo/McDual XO would be the best suitable solution. But you have to install them right before DAC as close as possible.
In this case, I don't thing you need an additional FifoPi.

Good weekend.
Ian

 

[JCMcNeil]

Thank you for the info, Ian.

So I would just run i2s from the Raspberry Pi header to the MiniSharc? Should I not do something to clean up the jitter and noise ahead of the MiniSharc?

Keeping the McFifo/McDual close to the dacs should be no problem as I have a large chassis available it will all fit in.

And are they currently available for purchase?

@ JCMcNeil

For multi-channels application, McFifo/McDual XO would be the best suitable solution. But you have to install them right before DAC as close as possible.
In this case, I don't thing you need an additional FifoPi.

Good weekend.
Ian

 

[JCMcNeil]

u.fl adapter for McDual/McFifo <--> MiniSharc?

A related question for anyone- is there an adapter/breakout board for the MiniSharc* to u.fl connectors?

Or would I need to come up with something? With MiniSharc and the 2 Scottish feuding clans McDual and McFifo** making seemingly such a good match, this seems like something that should exist if it does not.

*I had MiniDSP solder a female header to j2 (2x15 pins) on mine. By default they come with no header.

**Correcting jitter helps spacial recognition of the various pipes on bagpipes, right?

Thank you for the info, Ian.

So I would just run i2s from the Raspberry Pi header to the MiniSharc? Should I not do something to clean up the jitter and noise ahead of the MiniSharc?

Keeping the McFifo/McDual close to the dacs should be no problem as I have a large chassis available it will all fit in.

And are they currently available for purchase?

 

[wcwc]

I am not aware of any breakout boards for ufl connectors for the minisharc. I will essentially have two master clock sources upstream of a mcFifo. I have a FIfiPi (feeding through a HDMI receiver and a minisharc) and a MCH streamer (which can only be a master). Would I just not send the Masterclock signal to the McFifo?

The McFifo has 7 I2S data signals, which is what I need. I will be feeding 7 DACs so looks I will be designing my own clock board since McDualXO board can only support up to 4 DACs. I guess I could still use the McFifo.

 

[JCMcNeil]

FifoPi Q2 Ultimate + McFifo?

I am not aware of any breakout boards for ufl connectors for the minisharc. I will essentially have two master clock sources upstream of a mcFifo. I have a FIfiPi (feeding through a HDMI receiver and a minisharc) and a MCH streamer (which can only be a master). Would I just not send the Masterclock signal to the McFifo?

The McFifo has 7 I2S data signals, which is what I need. I will be feeding 7 DACs so looks I will be designing my own clock board since McDualXO board can only support up to 4 DACs. I guess I could still use the McFifo.

My understanding is you can only have one master clock source but maybe someone with more experience in such matters can chime in.

Similarly, I'm wondering if I can send the Master Clock signal from FifoPi to McFifo or if I really need to get McDual.

Or, maybe I could get by without McDual but the benefits are well worth the expense? But, then what about Master Clock conflict and if FifoPi isn't cleaning up the Raspberry Pi signals, won't that pollution permeate the whole system? Or can FifoPi lock in to an external clock from McDual? Or will they get into an, ummm, McDuel?

Cheers

Chris

 

[wcwc]

You need mcDual or some other clocking board after the McFifo. FifoPi won’t work in this application. You need 4 data connections. McDual gives you 7 data signals, 4 word clock, 4 bit clocks, and 4 master clocks. So you can connect 4 stereo DACs. I think you need the McDual board more than you need the FIfoPi.

Regarding the FIFOPi, it can only be a master. Minisharc can be either an input or an output slave. So you can have the McFIFO back feed the McDual masterclock signal to the minisharc. The RaspberryPi has no masterclock signal. So if you backfeed the clock signals it should do a good job on the RaspberryPi clock signals. If you are still concerned, you can use a FIFOPi after the RaspberryPi. Just don’t connect the masterclock signal to the McFIFO.

In my case, I think the McFIFO and McDual combo will work fine. My other 3 data signals are being fed from different boards with differing masterclocks and they are the center and surround DACs, so not as critical. So I I will run them without reclocking. I will also be using a FIFOPi since I already have it. My streamer is In a separate enclosure from my DAC. I will have a USBridge, ReceiverPi, FIFOPI, TransportPi. I have a HDMI receiver in my DAC that will receive I2S from HDMI in the TransportPi. So My FIFOPI is also reclocking the SPDIF signals on the TransportPi. I will not send the masterclock signals from the HDMI receiver or from the MCH streamer (my two inputs to the minisharc). I will feed the minisharc the McDual masterclock signal. I will have a decent delay on my audio due to going through 2 FIFO buffers, but I should be able to account for it in DSP.

 

[JCMcNeil]

jumping the Sharc

You need mcDual or some other clocking board after the McFifo. FifoPi won’t work in this application.

I see I need to study the McFifo manual as it wasn't clear to me that the FifoPi would not, umm, jump the Sharc.

Minisharc can be either an input or an output slave. So you can have the McFIFO back feed the McDual masterclock signal to the minisharc. The RaspberryPi has no masterclock signal. So if you backfeed the clock signals it should do a good job on the RaspberryPi clock signals. If you are still concerned, you can use a FIFOPi after the RaspberryPi. Just don’t connect the masterclock signal to the McFIFO.DSP.

I have the MiniSharc set up as both input and output slave as per the manual.

I functionally understand the Pi's limitations, I'm just not as clear on how the buffering can best enable jumping the Sharc forwards or backwards for reclocking. Going earlier in the chain with McDual seems counterintuitive but I suppose the buffer enables that. (?)

And I was not aware that McFifo could not use and distribute the clock from FifoPi, so thanks for.explaining.

In my case, I think the McFIFO and McDual combo will work fine. My other 3 data signals are being fed from different boards with differing masterclocks and they are the center and surround DACs, so not as critical. So I I will run them without reclocking. I will also be using a FIFOPi since I already have it. My streamer is In a separate enclosure from my DAC. I will have a USBridge, ReceiverPi, FIFOPI, TransportPi. I have a HDMI receiver in my DAC that will receive I2S from HDMI in the TransportPi. So My FIFOPI is also reclocking the SPDIF signals on the TransportPi. I will not send the masterclock signals from the HDMI receiver or from the MCH streamer (my two inputs to the minisharc). I will feed the minisharc the McDual masterclock signal. I will have a decent delay on my audio due to going through 2 FIFO buffers, but I should be able to account for it in DSP.

That's quite a system you have!

My understanding is that the MiniSharc will.not take a Master Clock signal when it is in slave/slave mode. I could bypass the Sharc and share the Master Clock directly with the DACs from FifoPi but these old multibit chips only want Bit Clock, Word.Clock,.and Data. (I also have some AD1865 chips to test and I understand I will need to adapt i2s to that chip's different needs.)

I chose slave/slave mode to access better clocks than the MiniSharc's and to avoid its ASRC, which the manual explains is not active in that mode. I've been warned it is dangerous and should be kept away from small children.

Instead, I use Volumio's resampling feature, with the quality algorithm set to "very high", Cheech and Chong style, to get the music in 96/24.

I imagine there must be better ways to resample than Volumio so (any random reader) please share any ideas.

I haven't finished building the first 4 (TDA1387 based) DACs but it sounds decent - at least as good as my well-optimized Allo.Boss 1.2 if not quite my Chord Mojo - playing full-range through my Audeze Sine headphones as I tweak DAC and IV-filter variables. DSP on the Sharc is set flat pending getting it into my primary system.

Thanks again for the insights.

 

[JCMcNeil]

Re: FifoPi Q2 Ultimate + McFifo?

I am trying to clarify my understanding on whether I need to get a McDual in order to use McFifo in my multi-amp system.

wcwc wrote "You need mcDual or some other clocking board after the McFifo. FifoPi won’t work in this application."

However, in the McFifo manual, I read "Works with McDualXO clock board, third party clock board or DAC local XOs." which, to me, implies I can send it the master clock from FifoPi Q2 Ultimate, jumping the Sharc in the chain, and let McFifo do it's thing to reduce jitter, especially that generated by the MiniSharc DSP, ahead of the 4 stereo Dacs.

The questions are,

1. will FifoPiQ2 Ultimate serve the master clock function in a system including MiniSharc and (post MiniSharc) McFifo as the McFifo manual seems to indicate? Or, do I have to switch to McDual for the Master Clock?

2. Or is McDual simply a better way?

3. And, if the latter, what makes it better?

Plan A: Raspberry Pi 4 + Volumio _> FifoPi Q2 Ultimate -> MiniSharc -> McFifo -> Dacs (etc)

-vs-

Plan B: Raspberry Pi 4 + Volumio -> MiniSharc -> McFifo -> McDual -> Dacs (etc)

I see I need to study the McFifo manual as it wasn't clear to me that the FifoPi would not, umm, jump the Sharc.

...
And I was not aware that McFifo could not use and distribute the clock from FifoPi, so thanks for.explaining.

 

[wealas]

Check your DACs and count how many MCLK, SCK and LRCK signals you will need. Then count how many of those the McFifo provides. You can't split any of those with just wires, for best results you need buffers and that's what the McDualXO provides along with the clock selection circuit the McFifo needs ( I don't know if that's exposed on the FifoPi).
Basically, you can feed one 8ch DAC directly from the McFIFo, but you need the McDualXO to feed 4 2ch DACs.

 

[JCMcNeil]

Check your DACs and count how many MCLK, SCK and LRCK signals you will need. Then count how many of those the McFifo provides. You can't split any of those with just wires, for best results you need buffers and that's what the McDualXO provides.

Ok, that makes more sense now. As I underatand it, I'll either need McDual or a 3rd party or DIY buffering solution for Bit Clock and Word Clock.

The DAC chips I am experimenting with - TDA1387, AD1865, and TDA1541a - don't require a Master Clock signal.

Check...along with the clock selection circuit the McFifo needs ( I don't know if that's exposed on the FifoPi).

MiniSharc requires or resamples everything to 96/24 so I don't think that's relevant to this project, but I get the point.

Thanks for taking the time to clarify. Since I already own The FifoPi Q2 I wanted to utilize it if possible. Now I see there is a buffering need that McFifo alone won't meet.

 

[bmxmen]

Hello i have an question. I have roon audio with raspberry pi bridge. Raspberry have moode 5.2 system . I have useing i2s connection by fifopiq2 reclocer. I have heard that reclocer needs 32bit connection to work. And only to get 32 bits i need to turn on parametric equalizer or resampling, becouse roon in this case decoding signal to 32 bits. it is only way to run corectly fifo pi q2 reclocer? or mayby need to change moode audio system for enother? Very thanks.

 

[iancanada]

@bmxmen

FifoPi can either follows the original input format or converts 16 bit PCM into 32bit losslessly. So, what format do you need for your system?

Regards,
Ian