The Well synchronized asynchronous FIFO buffer - Slaved I2S reclocker

Dithering is an option to avoid data truncation when input bit depth is bigger than output bit depth (eg. from 24 bit input to 16 bit output). Anyway dither can be excluded and data will be truncated.

We are using 8MB SRAM so the latency is in the range 0.5-0.7 seconds.

Hi Andrea, with so large buffer you do not expect it's over/under loading?
What are you doing, if this occurs?
 
First of all, I would really like to thank you Andrea, for the technical insight and the product you are contributing with to the DIY community. I am just dipping my toes into this, so one can safely say that a lot of your comments are way above my head, but I'm learning;-)

Two questions for you:
1 - Do you have a ballpark idea on pricing for your FIFO solution? (Sorry if you have postes this, and I have misser it)
2 - Will your FIFO solution (and the Light DAC solution) be part og your Clock group buy, og will it be a separate buying scheme?

Thanks again for all your contributions. For my part deeper insight following your comments leaves a lot of new questions, but that's how we learn:)
 
The ballpark pricing question also covers your descrete DAC, and power supply. Considering if I should buy the fifopi with your clocks++, or your total FIFO solution. I am also considering your DAC solution up against Doedes DDDAC 1794. Two very different designs, but from what I have found, probably the two best DIY DACs... Really looking forward to more information, especially where you see your solution pricewise, and if this fits my budget:)
 
First of all, I would really like to thank you Andrea, for the technical insight and the product you are contributing with to the DIY community. I am just dipping my toes into this, so one can safely say that a lot of your comments are way above my head, but I'm learning;-)

Two questions for you:
1 - Do you have a ballpark idea on pricing for your FIFO solution? (Sorry if you have postes this, and I have misser it)
2 - Will your FIFO solution (and the Light DAC solution) be part og your Clock group buy, og will it be a separate buying scheme?

Thanks again for all your contributions. For my part deeper insight following your comments leaves a lot of new questions, but that's how we learn:)

We have not yet defined the price of the FIFO Lite because it's still under test.

I'm not sure it will be part of the new GB, maybe a few months later.
The same for the DAC Lite, while I think that the battery supply system will be part of the GB.
 
I'm sorry but the DSD format is not provided by the FIFO Lite and neither by the top version.

Although the FIFO Lite provides I2S and PCM format suitable for the most DAC chip, we are developing these devices with a different approach, in simple words: low speed rather than high speed.
This allows to implement state of the art oscillators that's the real key in digital to analog conversion.
 
Disabled Account
Joined 2019
Will you ake an other GB or wait the Fifo to be ready to ship in the same time than oscis. ? Any news OF measurment about the new double Pierce at-cut board please ?


Hey you spent your holydays in Italy :D .... lucky guy :) !




Edit : a question came to mind : why not integrating a spidf and an usb on the TTWB(orn) Fifo to minimise the noise in the pass band signal of multiple boards and wires links ? (WHatever ou use Lcr and galvanic isolation on Datas and Bck) ! Seems there are interessant chips as the one Mark member is talking about and sold as an UsB to I2S on Aliexpress ? Does a relay will waste al the effort for input selection ?
 
Last edited:
The FIFO Lite has to be tested and optimized, so I don't think it will be available in the new GB.

The FIFO Lite has 4 x I2S input so one can implement USB, S/PDIF and so on using external converter.

External boards operate in a different domain, the FIFO takes care to isolate them from the DAC.
 
Raspberry PI as standalone source

Since we are planning to implement a Raspberry as a standalone source for our audio system, we have developed a few boards to interface it with our new FIFO.
The source includes the Raspberry PI, the 7" touch screen and an expansion boards to connect a SSD.
The SSD expansion board is stacked under the RPI.

The first board (TWSAFB-RPI) is an interface to the Raspberry and it's stacked onto the RPI. It provides power supply for the RPI and the Touch screen, and also a rail to supply the I2S transmitter. The I2S output is isolated from the Raspberry.

The second board (TWSAFB-TX) is the I2S LVDS transmitter powered by the TWSAFB-RPI.

The third board (TWSAFB-RX) is the I2S LVDS receiver to be placed far from the Raspberry and close to the FIFO. Its I2S output is isolated from the trasmitter to avoid any EMI/RFI interference. The input part of the receiver is powered by the transmitter, while the isolated output has to be powered by the FIFO.

An ordinary HDMI cable is used to connect the transmitter to the receiver.
 

Attachments

  • TWSAFB-RPI.jpg
    TWSAFB-RPI.jpg
    153.4 KB · Views: 688
  • TWSAFB-TX.JPG
    TWSAFB-TX.JPG
    165.7 KB · Views: 697
  • TWSAFB-RX.JPG
    TWSAFB-RX.JPG
    193.4 KB · Views: 698
  • TWSAFB-RX-TX.JPG
    TWSAFB-RX-TX.JPG
    287.1 KB · Views: 644
I wouldn't use the PC as the source so the USB is not practicable.

The Raspberry is a simple and cheap device to be used as a standalone source.

The problem is that the Raspberry generates a lot of EMI/RFI, so some precautions are mandatory (switch off BT and WiFi, keep the RPI far from the digital chain and so on).

Finally, if the FIFO does correctly its job nothing can pass from the source to the DAC. Otherwise, if the FIFO is source dependent IMHO there is somwthing wrong.

I see many members who struggle tweaking the Raspberry, using ultra low noise regulators to supply it or even removing the on board regulators.
But as I said several times IMHO the problem is not the RPI, the real problem is the FIFO that does not isolate the DAC from the source, that's the reason why we have choosen a totally different architecture.
 
I wouldn't use the PC as the source so the USB is not practicable.

The Raspberry is a simple and cheap device to be used as a standalone source.

The problem is that the Raspberry generates a lot of EMI/RFI, so some precautions are mandatory (switch off BT and WiFi, keep the RPI far from the digital chain and so on).

Finally, if the FIFO does correctly its job nothing can pass from the source to the DAC. Otherwise, if the FIFO is source dependent IMHO there is somwthing wrong.

I see many members who struggle tweaking the Raspberry, using ultra low noise regulators to supply it or even removing the on board regulators.
But as I said several times IMHO the problem is not the RPI, the real problem is the FIFO that does not isolate the DAC from the source, that's the reason why we have choosen a totally different architecture.

If you succeed with a 100% isolation with your Fifo that would be awesome.

But as long as there is also sound quality to be gained with the use of special audio graded switches (Uptone Etherregen and the likes), better ethernet cables, better power supplies on your router and switch, closer positioning of your music carrying NAS to the streamer, I doubt your mission will succeed.
 
But as long as there is also sound quality to be gained with the use of special audio graded switches (Uptone Etherregen and the likes), better ethernet cables, better power supplies on your router and switch, closer positioning of your music carrying NAS to the streamer, I doubt your mission will succeed.


I am pretty certain no fifo can remove these effects. Their audibility is just not related to the data stream.
 
I am pretty certain no fifo can remove these effects. Their audibility is just not related to the data stream.

TNT has just well explained (I believe he is a RF man with the right skills), keep the source as far as possible from the DAC and then connect them via optic fiber and no EMI/RFI can affect the digital to analog conversion. Fiber optic cable is a real brickwall against ambient RF.

Only one signal has to be connected via copper, the most important for the DAC conversion, in our case the LRCK. It must be as free of jitter as possible since it drives the DAC switching.
Don't worry about the jitter coming from the optical connection, the other signals (BCK and DATA) does not affect the conversion, the only purpose of these signals is to load the registry of the DAC before the switching.

But if you continue to believe that the right way is to stack all the digital chain onto the Raspberry without any real isolation and feeding the DAC by the FPGA, then I agree, you have no chance to really isolate the DAC from the source, the FIFO will remain source dependent.

Keep in mind that using a FIFO the source and the DAC operate in different domains, so there is no reason for the DAC to be affected by the source, unless the system was not well designed.
Usually audible effects are related to poor isolation and poor clock.

I don't know if we will reach the target with our FIFO Lite, there are a few compromises to get it affordable, but I'm pretty sure we'll get there with the top version.
Surely the oscillators we have designed are a big step forward to reach the target.
 
Last edited: