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

[Andrew Eckhardt]

I really hadn't considered what's been done in the past too heavily, in fact I don't really know. I figure that having this FIFO in hand, and I were still hot to mod the transport, syncing the transport clock is what I'd do. I'd probably leave the original mcu cyrstal or resonator there use a transformer and a very high resistance to couple onto the input side of what's probably a pierce osc on the mech mcu. Something stupid simple like that would probably cause permanent synch-up in a short while, provided the frequency is "matched". I don't know. Maybe it would be too hard to provide an aux output from the precision clock without adding precious picoseconds of wobble to the main output and you'd be better off with a "rogue" transport and tons of memory.

[qusp]

well, in that case i'll tell you, yes thats what people at the pointy end of this type of thing have been doing with various degrees of success for years (mostly not very); none of it gets close to what is actually a perfectly good system, i'm really not sure what you are trying to improve, or why

the fifo very deliberately went the other way and in doing so has produced the best result i've seen with fairly trouble free operation across the board given reasonable working conditions. it really isnt as simple as you think to make it all match and to do so, would be a completely different design, for which I would suggest you start another thread. …

weve got people in here with universally glowing reports, many calling it a game changer and you think youve got a better solution, which happens to have been done to death? not trying to be rude, really, but I find it really quite puzzling as to why you would suggest to get rid of the fifo buffer from the fifo buffer project in the fifo buffer thread, to the fifo buffer fanboys =)

[Andrew Eckhardt]

I was thinking that since completely asynchronous operation is possible (after this project, suppose), it creates an opportunity for synchronization by practically simple means with very small amounts of control current (small enough to be drawn from the main osc without ruining it). Call it a paradox if you will. In fact the full amount of memory in some cases, if not all, may still be necessary. I didn't mean to challenge the Hermetic Order of Asynchronicity, but I don't believe the asynchronicity is what makes it work, it's just a side effect of making it work the way this project does. Anyway, I don't know that it can be done well or better. I was just answering a question asked about what can be done to the transport now that nothing but the words matter. If everyone already knows that's actually better in my view.

[iancanada]

Originally Posted by anaeroben

Hello,

About source/fifo clock frequency difference, it is believed that most difficult to manage is when source frequency is lower than fifo : buffer have to be filled enough before starting to deliver output samples to avoid running out of samples. Ian, is it so that what you call smart strategy adjust buffer length according source/fifo frequency difference (:-) !!
Understanding is it worth to minimise frequency error of source (avoid low end sound card ?), PLL solution is better to deal which frequency difference but then bye-bye killing jitter performances !
One silly question, could fifo input be USB (so source frequency > fifo)?
It's a long way, but hoping, i can mange to built a DAC board to be used with fifo.

benoit

Hi Benoit,

Actually making a really nice low jitter clock is very difficult, however making a clock comes with good ppm is very easy. The worst audio clock I have ever met was from a CDROM, but few of them worse than 100ppm. The audio clock form a PC or a Mac or a USB are even better. FIFO normally doesn't have problem with this kinds of sources.

FIFO never change any bit on data, nor track the input clock frequency. It 100% bit perfect guaranteed, and the clock is also 100% original. The FIFO controller may adjusts the FIFO deepth at the middle of silence when it close to full or empty. So, usually FIFO doesn't going overflow if you source is not too bad .

The bigest problem of a FIFO is the buffer delay. For music play back applicatrions is OK. But for editing or multi-track recording, or video synchronizing, gonna be problem.

Regards,

Ian

[iancanada]

True story: My boss is the kind of guy who always comes up with new idea. At the beginning, he came back for me, “Ian, how about we include this feature in the project?”, I said,” …Well….it’s achievable…but I need two weeks more…this section has to be re-designed.” Later on, I could roughly guess what his new idea is gonna be. So, I’ll leave some backdoor in my design. And now, when he says ”Ian, I have a good idea…” I say, ’’ That’s great, I like the idea, I’ll show you something tomorrow” J .

Yes, you’ve already guessed there is a backdoor for the I2S input. I noticed there is a strong requirement on switching between S/PDIF and I2S sources before feed signals into FIFO. So, I think I have to tell the secret. The I2S input backdoor is left on the S/PDIF interface board. But it needs a new version of FPGA firmware support to open. Now, my questions are:
1, Do you need I upgrade the FPGA firmware for the GB II to support this I2S backdoor?
2, With the I2S backdoor enabled, the S/PDIF board sources selecting loop will be: OPT->COX->TTL->I2S->loop back, is that OK?
3, Although I left the I2S backdoor, but I didn't place a real connecter footprint on the PCB, only 4 SMT resistor’s footprints. So I have to say the backdoor is not that perfect. You have to tap a 4P PH2.0mm connecter by yourself as the picture below. Does it work for you if you really need this I2S input backdoor?

Have a good night.

Ian

[zinsula]

Hi Ian,

1) at the moment i do not need I2S, but it would be certainly helpful, if one wants to add an USB to I2S device, or a second S/PDIF to I2S receiver. Who knows!


2) I have rather another "issue" related to this source selection.
I'm planning to build the S/PDIF and FIFO with DAC into a Preamp, which can switch between analog line level sources and the built in DAC.
If i want to connect two digital sources to the S/PDIF input board (eg OPT and COX), the toggling functionality isn't really great and would not be compatible with the preamps input selection. For me, direct input selection would be better....
See, I'm kinda like your Boss ;-)

3) Regarding the connector, well one has to try...

Ciao, and thanks

[qusp]

direct input selection by software with assigned numbers, rather than cycling through? I think hes trying to avoid redesigning the board, as i'm sure are those waiting. …

I would think it wouldnt be difficult to send enough pulses in one command to make it act like direct

[NicMac]

To me it seems that opening the I2S "backdoor" is all benefit and no downs.

I can wait - so it gets my vote for GBII.

Cheers,

Nic

[PET-240]

Just so I follow, if I'm using a USB to I2S device as source I can input direct to FIFO not SPDIF board. However if I want SPDIF input as well I would need to use the back door method?
I'm all for extra functionality as long as I understand.
Also I figure for pause we must wait till buffer empties before music stops?

[zinsula]

Originally Posted by qusp

[...] I think hes trying to avoid redesigning the board, as i'm sure are those waiting. …

Don't worry, of course I do not ask to redesign the board.

Depending how the selection is done, it might be possible to access the MUX pins directly. Will check that with Ian directly, didn't want to flurry anyone here.

Originally Posted by qusp

[...] I would think it wouldnt be difficult to send enough pulses in one command to make it act like direct

Depends how skilled one is in programming and what selector system he has already for this task.