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

ES9038 DACs are so far the best DIY DS DAC. But has to be run at SYNC mode with decent clocks. ES9038 Pro is basically more ES9038Q2M in parallel. I like my ES9038Q2M Dual mono DAC with OPA861 I/V stage. But if I have time, I'll develop a ES9038 Pro DAC.
Why not a ESS9039PRO Dac?
Sans titre-1c.jpg



https://reference-audio-analyzer.pro/en/report/dac/smsl-su-9-pro-fast.php#gsc.tab=0
 
Last edited:
Hello @iancanada , all!
I am using FIFOPi Q7 with HDMIPiPro connected with a straight HDMI cable with Musician Audio Pegasus DAC.
Based on HDMIPiPro output connector pinout and the DAC's manual, I am using MODE5 on DAC settings, but the channels are inverted.
What do you think could be the problem?
Thank you!
View attachment 1129357
View attachment 1129358
If the channels Arena Inverter just switch DATA i.e Mode7.
I hat the same problem.
Regards, Martin
 
Hello @iancanada , all!
I am using FIFOPi Q7 with HDMIPiPro connected with a straight HDMI cable with Musician Audio Pegasus DAC.
Based on HDMIPiPro output connector pinout and the DAC's manual, I am using MODE5 on DAC settings, but the channels are inverted.
What do you think could be the problem?
Thank you!
View attachment 1129357
View attachment 1129358

Please try Mode6 if channel inversed. The DAC user's manual may not be 100% correct.
 
  • Like
Reactions: 1 user
@ Supersurfer,

That's a good question.

The low jitter I2S/DSD signal quality of FifoPiQ7 gets really improved over Q3. That's why both myself and many other audiophiles experienced improvements on sound quality of FifoPiQ7.

The other features too. For example, the continuous clock mode, works great to eliminate the pop sound of some DACs when start/stop music or change Fs. That is another significant improve to the SQ. And as well as the SYNC charge mode, it will keep the output of the UcPure ultracapacitor power supply always stay at the most optimized voltage to ensure the lowest possible phase noise level of the clocks that used on FifoPi Q7. The delay time too, it controls the depth of the huge FifoPiQ7 memory buffer and uses a smart way at the same time to make the depth variable according to the Fs, to implement a same delay for different Fs. You can use shorter delay time ( for example 0.1s) if you watch video at the same time, or you can use longer delay time to use bigger memory buffer, say 0.8s, for music. As same as setting how many memory you use for the memory direct mode in the software.

Ian
Ok, you convinced me, I ordered one. But if it is not better than my current stuff I want my money back😉
 
For PCM music, LRCK decides the left and right.
LRCK=0: left channel
LRCK=1: Right channel
https://www.sparkfun.com/datasheets/BreakoutBoards/I2SBUS.pdf

The user's manual of you DAC looks unreasonable, could be something wrong.
Thank you again!
I made tests on all 8 modes of my DAC, using flac and dsd files from "Channel Test Tone By Jeffrey Richards" and this are audible results:

1673602839797.png

Seems like MODE5 and MODE7 have no "out of phase" neither on PCM or DSD, but the channels are inverted.

Anyone here with this combo HDMIPiPro and Musician Audio Pegasus DAC?
 
Thank you again!
I made tests on all 8 modes of my DAC, using flac and dsd files from "Channel Test Tone By Jeffrey Richards" and this are audible results:

View attachment 1129631
Seems like MODE5 and MODE7 have no "out of phase" neither on PCM or DSD, but the channels are inverted.

Anyone here with this combo HDMIPiPro and Musician Audio Pegasus DAC?
Seems the Mode5 is correct, but the DAC inverses the channel internally somehow.
 
For PCM music, LRCK decides the left and right.
LRCK=0: left channel
LRCK=1: Right channel
https://www.sparkfun.com/datasheets/BreakoutBoards/I2SBUS.pdf

The user's manual of you DAC looks unreasonable, could be something wrong.
You realise that I2S is not a standard? The LRCK can be whatever you want it to be. It has such a different meaning in different "flavours" of I2S that gets different names like "channel strobe" and also analogous to the "Chip Select" or "Slave Select" in SPI where the protocol is derived. In that you can do anything you want with the slave/chip select line and can thus use it to communicate addition information that the slave device might need.... such as "channel select". Originally Left/Right (the order is not specified except in the tables of variants), can now be used as the channel select strobe of sometimes just frame strobe to mark "channel 0" and you can send as many channels of audio you want. Hell, you can throw a few non audio streams in there too if you so wanted.

"You" in the above would be a low level digital engineer of course. Which means the people who make your ADC/DAC/DSP or whatever bit of hardware.... 'they' decide what parameters and how they use I2S and that depends on who or what they are trying to be compatible with.
 
  • Like
Reactions: 1 user
I indentifed with the original post. In the given nature of processing audio in an MCU in "buffer sized chunks" and "remastered" I2S at the output it's more or less the same thing.

The challenges I am facing is not just keeping one stream at bay, but many. This adds the "buffer alignment" to the mix in addition to clock slew/drift. If you want to mix 3 I2S streams with 1ms buffers, you need to wait until 1ms of audio is available from all streams, mix and output. A 1ms buffer can slip by up to 1ms so there exists the potential for a source to "slip out of frame" entirely.

Beyond that however I need at least 'some' of that 1ms to actually mix the channels and prepare the output before the 1ms window on that output buffer closes also. That means the source buffers have to be pretty well aligned and kept pretty well aligned.

Brings me to my first critique of the OP idea. Hoping to use 2 clocks which are not synchronised and expecting them to remain "close enough" just isn't going to happen. They will slip, they will drift. How much and what impact depends entirely on how much you want to spend on the crystals and their circuitry and how long your buffers are.

You can get a (over) estimate or a worst case just by taking the two extremes of the crystals' accuracy. A 24Mhz clock with a 10ppm accuracy can be out by 2.4Hz(?) two of them gives you a worst case of 4.8Hz. Given your bitrate, buffer size etc you can calculate how much "word alignment drift" will occur over what period. With 10ppm clocks it works out pretty "ok" with a 1ms drift only possibly every 8 hours or something. You are unlikely to see this kind of differential though. You could go a step further and buy a tray of crystals and, after properly condition matching them, test them and pick the best matched pair, with a 4 channel scope this could go pretty quickly.

If you are an audiophile you might be upset to see the bit drift rate at 192KHz 32bit will be pretty often. I haven't run the numbers. Basically 8 hours divided by the number of bits in that millisecond of audio for your setup.

Of course those are worst case and if you pick matched cystrals (even manufacturer batch numbering if they support that method) and you maybe buy 8 and pick 2. That 1ms drift every 8 hours becomes more like 1ms drift every 10 days.

Even at the 8 hours, or even 4 hours. You can sneak a periodic stream reset in there during a period of silence or noise floor. Any time it gets the opportunity to drop a frame and realign basically.

Even running from the same clock doesn't guarantee perfect, 0 bit drift.

The low levels of clocking are formidable in mathematics and the study of clock synchronisation circuits and replacing your "additional" clocks with resonators excited by the input clock (making them synchronous) may or may not help.

To be honest I think if you are chasing "bit jitter" and drift you are disappearing down a very, very deep rabbit hole. I'd assess the benefit over the effort and cost and check my biases carefully before proceeding further.

An interesting technique I am just discovering and exploring the use of is STM32's SAI peripherals. They can be in master or slave I2S mode, each having 2 audio ports. You can however synchronise ports within an SAI block or synchronise multiple SAI blocks together. This "aims" to sync the bit clocks and LRClk between streams in slave and master which normally can't be done without external shared clocks in I2S.

EDIT: 10ppm in 24.576Mhz is actually 245.76Hz, not 2.4. Something to consider. That buffer drift comes down from 8 hours to 5 minutes.
 
I'm quite sure the dual mono 9038 would, correctly setup, outperform my current mytek brooklyn bridge dac.
So Pi4 2Go, Linear Pi solo and UcConditioner 5v -> FifoPi Q7 + Accusilicon 90/98mhz/ and UcPure 3000F 3.3V->Dual Mono DAc - >Uc Pure 3000F 3.3v (ideally 3 independant 3?3V would be perfect) -> transformer IV and UcPure 3000F 3V. WIth a linear PSU like KECES P3. that should be good enough to make me discover a whole new level, while dropping my roon server (I9 9900) and my mytek dac.
A good way to also save a bit on the power bill:)