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

Hey Ian, yeah sorry i should have linked it and i forgot the dot in w.fl, its that type, but the one i'm using is a touch more upmarket, its made by hirose and comes available with double shielded mini coax cables, it looks to be the same, or at least similar connection standard as the one you linked, but its a bit pricier and does seem, or at least looks higher quality. its also described as ultra low coax smd, so perhaps its lower profile.

Hi Qusp, Thank you for the update. I sourced them by those info. They are from Hirose and there are W.LF(2*2) and U.LF(3*3) two series. like: Digi-Key - H9161CT-ND (Manufacturer - U.FL-R-SMT(10)) and Digi-Key - H9173CT-ND (Manufacturer - W.FL-R-SMT-1(10)) . I will try to get some samples and to see if I could use them. BTW, very professional baord desing, as well as the smart idea about the digital audio interconnection. Regards, Ian
 
Do you detect "silences" between songs and allow the fifo to go to half full again (remove/add some silence)?

But indeed interesting. Seems easier than trying to build an extra pll :D
Hi GuidoB, Thank you for interesting. You are smart guy. You know the secret! Totally agree with you. Yes, in this design, the smart FIFO strategy has already been included inside the FPGA. That means, for the continuous music signal, the FIFO overflow time is 1486s(under those conditions), but for the normal music playback, the fifo depth could be adjusted during the silence between songs to keep it at certain level. So, for most of the cases, FIFO will not overflow and you will never feel the existence of the FIFO except the delay. Cheers, Ian
 
Last edited:
The FIFO playing test

Finally, it starts playing and it sounds correct. The FIFO concept is working!

I2S FIFO configuration:
I just have a spare AD1955 DAC board. It has onboard I2S input and output ports which could be very easy to interfaced with my FIFO. Those ports were designed originally for the DSP, but in its normal setup, the I2S bus was bypassed by jumpers. Both input and output ports of the I2S on the FIFO are the 7pin connectors, 4 of 7 pins are GND between the signals to reduce the crosstalk.
The DAC has a coaxial SPDIF input, the DIR chip is BB DIR9001.
The FIFO was driven directly by an external OSC (11.2896MHz for 44.1KHz with MCLK 256*Fs), as well as the MCLK input of the AD1955. And now you can see this OSC become the secondary clock of the new clock domain and has nothing to do with the MCLK generated by the DIR9001.
I use batteries to power the OSC and the FIFO. The CYCLON battery is my favorite. Batteries usually come with less noise and much better performance to power the clock related circuits which are very sensitive to the noise from the power supply.

The system setup:
Speakers: B&W Nautilus 804;
Power Amplifier: PASS LABS ALEPH 5 (DIY, clone);
Pre-Amplifier: PASS LABS ALEPH P1.7 (DIY, clone);
Source: KRELL KPS 20i/L CD transport & MAGNAVOX CD player

Testing result:
1. It sounds correct, just confirmed the bit perfect test I did before;
2. When I switched the SPDIF cable from KRELL KPS 20i/L CD transport to MAGNAVOX CD player, it sounds same no any audible difference, the FIFO concept is working!
3. When I bypassed I2S signals on the AD1955 board, and let them come directly from DIR9001, it sounds different;
4. The delay was around 0.5 to 1s and not that obviously. It just feels like a bit slow on the button of the CD player. I could hardly notice it in most of the cases;
5. FIFO didn’t overflow during the entire test.

Since the FIFO board is working, now we already have a platform to taste the different clock oscillators. So, the next step I’m gonna do some test connected to the clock.

Enjoy my basement. Have a nice weekend. Ian
 

Attachments

  • I2SFIFOandDAC.JPG
    I2SFIFOandDAC.JPG
    473.4 KB · Views: 5,985
  • B&W804Speakers.JPG
    B&W804Speakers.JPG
    290 KB · Views: 5,769
  • Krell20iCDtransport.JPG
    Krell20iCDtransport.JPG
    410 KB · Views: 5,469
Last edited:
looking good Ian, i too prefer batteries for clock and also use them for powering the analogue sections of the dac (3v3 for AVCC L/R and 1v2 for analogue reference) but I use LiFeP04 by A123. what battery chemistry are the Cyclon?

beautiful speakers btw, the B&W are some of the best i have ever heard. Thats a pretty serious Disk spinner you have there, is that face actually made of stone haha, or just a finish on the alloy. it looks like it opens up Star Trek style.


I cant take credit for the Dac layout in the picture, Acko did that (thus Ackodac) i did however push for using the micro BNC for all inputs on the upgraded Teflon board (having owned the previous version as well), which was to be a limited edition when we got the first small run of 6 boards (4 for me, 2 each for me and vy friend); but turned out so well it became standard.

I have used them in a few of my own builds since then, but that one wasnt me.

this project of yours us quite interesting for my spdif sources, I cant see it making an improvement on my usb->i2s setup, which might actually complicate the use of your board with my main dac unless i run it from the same master clock, which i guess is the idea, muxing might be difficult though.

regardless i do have another dac in the workshop rig it will work well with, so when you finish testing and do a board run let me know, i'll pop my head in from time to time.
 
right i checked them out, cyclon are SLA? mate if you like batteries, i really recommend you try out LiFeP04, imo it leaves all other battery chemistries in the dust. output impedance is very very low, noise is lower than SLA, charges in a jiffy and even just the smallish size 3v3 (nominal) 2300mah ANR26650m1 is capable of 70A continuous output with burst rate up to 120A!! output impedance is less than 10mOhms and the nominal voltage is extremely convenient for digital circuits.

i'm quite amazed at the rate of your progress also!!
 
Glad to know that someone has the similar interest. Nice board!

I started a similar project in the summer of '09. The basic idea was very similar, only that the I/O peripherals have more varieties. Instead of I2S I/O, I also added S/PDIF I/O (via BNC and XLR), isolated USB input and an LVDS I2S input over HDMI cable compatible with the PS Audio spec. I was able to get a few 1MB (8Mbit) SRAM (those are not cheap if you buy new) for a slightly deeper FIFO depth. I used an old FPGA that is large enough for the logic. The actual FIFO depth is determined by measuring the clock frequency difference between the incoming signal and the local reference clock, such that the minimum amount of FIFO is used to reduce latency. In addition to PCM, the logic also supports DSD64 (in a 176.4KHz/16bit PCM container when transported via S/PDIF or I2S).

Soon I found that the FPGA I picked does not have the ideal clock resources I need, and the logic resource is not enough for future expansion. I had to abandon the board that I spent quite some time to layout, fab and assemble, let alone the cost of the parts. The core logic is not complicated, but I want to add more 'fun' to it.

Then I turned to a low-cost FPGA development board, the Digilent NEXYS. It has almost all I need for a digital audio front-end: a 500k Gate FPGA with DCM and multipliers, 8MB(64Mbit) PSRAM (DRAM+controller that works like an SRAM), 32Mbit NOR flash and a USB 2.0 high-speed device controller. The I/Os are more than enough for the audio application. A character LCD interface with the switches and push buttons make a reasonably good UI.

A more elaborate plan was laid out: turn the all-hardware design into an embedded system. A PicoBlaze CPU was added for user control and status indication on the LCD. It opens a can of worms and I quickly realized that the software is the most time-consuming part of this project. In this new platform, I was also able to add S/PDIF receiver and transmitter logic such that I'm no longer limited by the features of the off-the-shelf S/PDIF Tx/Rx ICs. A firmware was developed for the USB 2.0 device controller for USB audio class device that is capable of Hi-res.

Again, it wasn't long before I realized that the old architecture has become the bottleneck of this system. I can do a lot more on this platform: A 32-bit CPU with enough performance to run software FLAC decoding, an SDIO interface that enables solid-state player function, oversampling and decimation filters using the FPGA multipliers, etc, etc.

Unfortunately, while I was going full-steam with this project, I was interrupted by a business trip, followed by a serious personal incident that almost knocked out all my interest in this project.

I guess that's it. If you have plenty of time and ambition, think big, or soon you'll find yourself being trapped in a small PLD, a small PCB, or an architecture that is just enough to do what you thought of at the beginning.

It wasn't a bad idea to sell a few boards while you make new ones, though. That'll encourage you to move forward but could also slow you down with the support responsibilities. It depends. Good luck!

(Attached is the 'discontinued' board, only one was made)
 

Attachments

  • DAKS.jpg
    DAKS.jpg
    309.4 KB · Views: 5,308
I would be interested in just the fifo function, not a complete set. Maybe also a programmed fpga to integrate on my own pcb later on.

Bit of a lego construction; add an spdif receiver on one side (have a small pcb available) and a filter/dac/clock on the other side.

But then, i could also continue with the pll. Or just buy something nice :rolleyes:

I'm wondering about live concerts, in case there are no silences inbetween the songs. What happens if the fifo runs full or empty ??
 
The problem is the RAM size. Large SRAM is not cheap and not easy to come by. Or you can go DRAM with a slightly more complex memory controller. Since the RAM size needed is the function of supported sample rate, bit depth and clock frequency difference, one can calculate how much RAM is enough.
500ppm is a good, practical starting point, but I would opt for 1000ppm, which is IEC60958 standard for S/PDIF streams. In order to support a stereo 192KHz/32bit PCM stream at 1000ppm clock frequency error without FIFO overflow over a continuous 1.5 hour playback (gap-less), you'll need about 8MB (64Mbit) of memory.
 
Today CAS become more and more popular, considering a DAC may not just or even no more for CD playback, and more and more 24/88.1 or higher rate files could buy or share online, I will suggest do more test for 24/88.1 or higher rate playback, plus maybe even upgrade the FIFO support up to 384KHz, since 32/384 USB DAC or USB-I2S interface starting appear in the market already.
 
The problem is the RAM size. Large SRAM is not cheap and not easy to come by. Or you can go DRAM with a slightly more complex memory controller. Since the RAM size needed is the function of supported sample rate, bit depth and clock frequency difference, one can calculate how much RAM is enough.
500ppm is a good, practical starting point, but I would opt for 1000ppm, which is IEC60958 standard for S/PDIF streams. In order to support a stereo 192KHz/32bit PCM stream at 1000ppm clock frequency error without FIFO overflow over a continuous 1.5 hour playback (gap-less), you'll need about 8MB (64Mbit) of memory.


Considering even a typical FIFO interface already not simple to general DIYer, anyone like you and now Ian willing to start the game, should be not mind about the price of SRAM, although cost still matter, but think about all time and effort which we could use for earn much, the SRAM become nothing...... Sorry for my poor English, I hipe I sucessfully express my thoughts and all of you understand.
 
looking good Ian, i too prefer batteries for clock and also use them for powering the analogue sections of the dac (3v3 for AVCC L/R and 1v2 for analogue reference) but I use LiFeP04 by A123. what battery chemistry are the Cyclon?

beautiful speakers btw, the B&W are some of the best i have ever heard. Thats a pretty serious Disk spinner you have there, is that face actually made of stone haha, or just a finish on the alloy. it looks like it opens up Star Trek style.

Hi qusp, sorry the late reply. I was out of town on this long weekend. The Cyclon battery is a kind of lead-acid battery with special internal construction. It's one of the few which could touch the medical grade due to its wide temperature range, long life, high current and low noise. The LiFeP04,you recommended, looks has higher current density and smaller size, I'd like to try it later on. Yes, the KRELL KPS 20i/L CD transport was one of the top of the line in the 90's. Very clasical like a mailstone. This model is very special one, internally, it integrated a CDM9pro CD tranport unit and a 4*PCM63K DAC unit together, but at same time, they independent from each other. I bought it used for more than $5K five years ago just because I need a reference DAC and a reference SPDIF source for the developing of my CD transport project. So are the B&W 804 speakers. All of them are also usefull for my current I2S FIFO project now. Without listening compare with those top toys, I even don't know how far I could go. Thanks again for the follow up. Have a good night. Ian
 
I am glad that there is somebody that thinks like me around here. When I was discussing on another thread that the FIFO cache is the only good way to eliminate jitter, I was told that CD controllers have enough FIFO (yes, all 4kB of it :)).
Unfortunatelly, I don't have the spare time to do to much DIY projectes like I used to when I was younger.
Good luck with your project, looks like you are on the right path.
 
Glad to know that someone has the similar interest. Nice board!...
Hi Simmconn, Thank you for sharing your experience with us. You did great job, Simmconn. Very nice board design. Congratulations!
You must be a very experienced electronics design engineer. To achieve that project, you need a lot of knowledge and skills such as FPGA design, signal processing,circuit design, PCB layout, embeded processor design as well as the full range of digital audio technologies. I'm very glad to know that somebody else in the world had the similar idea and interesting with me. At least, it proved, I'm not the alien :)).
My idea of design a I2S FIFO started from 5 years ago. At that time,I was developing my CD transportat. During the test, I found that the different clock source of the CD transprot result in great difference on the sound quality.But no matter how much care I took on the clock, there was still some kind of barrier blocking the improvement of the sound quality of play back on the DAC side.
So I went a bit deep and did some reserach on the master clock tree. it was like this: master clock -> DIT -> SPDIF driver -> pluse transformer -> coaxial cable -> pluse transformer -> SPDIF receiver -> DIR -> PLL recover clock -> DAC; The clock route was too long and each section would introduce big amount of additive jitter. Especially the flip-flop inside the DIT chip and the SPDIF driver except the master clock itself. Although the high range jitter of the recovered clock was determined by the PLL, but the PLL still tracing and locking the low range of input clock together with the jitter below the corner frequency. So finally I realized that the solution would be introducing a brand new low jitter clock to isolate the recover clock and feed the DAC directlly without any buffer and flip-flop in between. The answer was asynchronous I2S FIFO.
I didn't launch this project until last Christmas vacation. Since then, I started this I2S FIFO job from the verlog coding. Step by step, I wrote different modules and simulated and ran them one by one on my CycloneIII EP3C16 board. I did a lot of simulation and test before I went the real hardware.
Yes, you are right, this project is not limited to pure I2S FIFO. With the clock board, it is the I2S FIFO to boost the DAC; with the DIR, it become the SPDIF receiver with the buildin FIFO and low jitter clock; with the DIT and DIR, it become the SPDIF FIFO; integrated with DAC, it become the high performance low jitter DAC with buildin FIFO; with the MCU, it become the digital audio front end. There are a lot of extension in front of this project.
On this projcet, one of my opinion is: improtant of the important is the clock. Now, I have already switched my focus point from FIFO design to clock board design and looking for better clock source. Because the FIFO is only a logic function,but what really influence the sound quality is the low jitter clock.
Simmconn, just hope everything is well with you now. You should continue your project and keep bringing the 'fun' both to you and to us.
It was very nice meeting you in this thread. Thanks again for all. Take care. Ian
 
Last edited:
I am glad that there is somebody that thinks like me around here. When I was discussing on another thread that the FIFO cache is the only good way to eliminate jitter, I was told that CD controllers have enough FIFO (yes, all 4kB of it :)).
Unfortunatelly, I don't have the spare time to do to much DIY projectes like I used to when I was younger.
Good luck with your project, looks like you are on the right path.


Your point of view is correct, SoNic_real_one. Totally agree with you. 4KB and 4MB make big difference :) .
Thank you and have a good night. Ian
 
Last edited:
Considering even a typical FIFO interface already not simple to general DIYer, anyone like you and now Ian willing to start the game, should be not mind about the price of SRAM, although cost still matter, but think about all time and effort which we could use for earn much, the SRAM become nothing...... Sorry for my poor English, I hipe I sucessfully express my thoughts and all of you understand.

In the DIY community, the development effort is usually not amortized into individual units, which makes the part cost the primary concern. Having a low total part cost would just benefit everyone, right?
 
Today CAS become more and more popular, considering a DAC may not just or even no more for CD playback, and more and more 24/88.1 or higher rate files could buy or share online, I will suggest do more test for 24/88.1 or higher rate playback, plus maybe even upgrade the FIFO support up to 384KHz, since 32/384 USB DAC or USB-I2S interface starting appear in the market already.
Hi Goldkenn, thank you for your reply.
Actually, the FIFO section just isolate two I2S domain and has noting to do with the Fs. You can feed it with 384K/32 bit stream without any problem if you could provide suitable mclk. (only the mclk decide the Fs, not the FIFO). Accodring to the simulation result, the max mclk of this FIFO could go upto 120Mhz.
The clock boards I'm cooking right now will support upto 192Khz/24/32 Fs, for sure. Talking about 384KHz/32... actuall I could... but I don't have much PCB space...just let me think about it. Thanks, Ian
 
I'm wondering about live concerts, in case there are no silences inbetween the songs. What happens if the fifo runs full or empty ??

Very good question, Guido. I'm afraid if the FIFO is empty, it will sound like repeating a word(around 1s for 44.K), and when it full, it will sound like short a word(around 1s for 44.K). Meanwhile, no pause,silence and other noise. Just imagine if you have a cassette, cut 1secnd length or extend it with 1 second copy, would be the same thing as FIFO full and empty.
When you play the continue live concerts, this will happen every couple of hours if the sampling clock is not that bad(with 100ppm frequency tolerance).

PLL is another solution. According to my quite limited knowledge on this issue, the key thing should the bandwidth. If you reduce that bandwidth to a certain level, you might still need a FIFO to buffer the data, but may not that big ...
Maybe I'm wrong or you have some good idea..anyway, good luck to your project. Have a good night. Ian
 
Hi Simmconn, Thank you for sharing your experience with us. You did great job, Simmconn. Very nice board design. Congratulations!
......

Simmconn, just hope everything is well with you now. You should continue your project and keep bringing the 'fun' both to you and to us.
It was very nice meeting you in this thread. Thanks again for all. Take care. Ian

Thank you, Ian. You must have realized that even though the idea is straight forward, it takes a lot of time and effort to make it happen, not to mention the scope of knowledge it requires.

I, too, realized that the clock is critical. However, with often misleading specifications published by the mfgs, the quality of clock is somewhat subjective (as a matter of deciding who you choose to believe :D). One can make a multi-stage crystal-filter based oscillator, or have a digital audio frequency OCXO custom made, or even use a Rubidium clock (not that I recommend it, though). For the most 'fun-factor', a FIFO board would be BYOC (bring your own clock).

What made me a bit skeptical about a piece-meal I2S board approach is that a less-than ideal wiring (especially the digital signals) can easily counter the benefit of the FIFO. Using an SMA tee connector on the clock line seems to indicate that you are not an RF engineer:). Me either. I learned a lot from the folks at diyhifi, but still too little to tackle the clock issues.

By the way, I noticed that the SRAM on your board is 256kx16 (4Mbit=512kByte, not 4MB). You might want to use the lower case 'b' when mention it.
 
Consider the intrinsic jitter of any complex chip you are using. In this design say we have an incredible transport with documented 3ps jitter delivered to the DIR9001. After the DIR9001 we will have 53ps (+- based on the mckl per the datasheet), this intrinsic jitter is always added and has nothing to do with the corner frequency, above the corner frequency is where the 3ps from the transport will be passed (worst case).

No we have your FIFO, feeding your chip a high quality clock, great now we have jitter equal to intrisic jitter of the FIFO chip + clock jitter. Now I'll bet a few dollars the chip used here has more intrinsic jitter than a 9001 which was specifically layed out for digital audio. So I guess what I am saying is if your transport is very good, your FIFO will probably add overall jitter.

Solution is easy, simply reclock the output with the same crystal, this will eliminate the FIFO's potentially high intrinsic jitter. This technique has been used for years dealing with CD decoders, it works and should be considered here.