• These commercial threads are for private transactions. diyAudio.com provides these forums for the convenience of our members, but makes no warranty nor assumes any responsibility. We do not vet any members, use of this facility is at your own risk. Customers can post any issues in those threads as long as it is done in a civil manner. All diyAudio rules about conduct apply and will be enforced.

New FIFO buffer for RPI/SBCs

You mentioned that for galvanic isolation you would need to isolate a bunch of signals other than those used for I2S (SPI, I2C, etc.).

You are referring to signals that might be useful to DACs or other devices that will stack on top of your FIFO board, right?

I mean, the actual FIFO board doesn't have any use for any of these signals, right?
 
Member
Joined 2003
Paid Member
We have designed a new DAC working with any SBC/RPI (i2s)

We are using 2 DAC ics PCM5142 with integrated DSP. The PurePath software from TI is available for download (registration required) and can be used to create specific filters and other audio functions.

The board will come pre programed as a 2.1 output (but you can create your own custom design and load it the board and can access the xover frequency directly from linux (we made a small app)

Hardware wise , we have split the digital and analog side with LDOs and we feed the analog side using an extremely capable (low noise ultrahigh psrr) LT3042. Basically each board has 4 LDO (2 for each DAC ic) (note that digital side uses cheaper LDOs)

Of course , on the analog side we used only thin film resistors and poly caps in audiopath.

This DAC has RCA outputs but also a small connector that will connect to our TPA3118 AMP shield (only LR)

Looks very interesting. I like what you've done to filter the power... is there an option to power the DAC separately from the Pi without cutting traces?

John Swenson also planned to use this type of configuration with a board he designed to work with SqueezeLite, where he had two DAC chips that in the basic configuration would be used to product a balanced output, but could be configured for a 2-way output.

Thanks for sharing and I look forward to it being available.

Greg in Mississippi
 
RPI has an on board xtal of 19.2Mhz. For the 44.1Khz audio the LR Clock must be running at exactly 44.1KHz, but this is not possible since the frequency is not a multiple of 19.2MHz. So RPI will either run at 44.138 or 44.036Khz

With a FIFO buffer everything is re clocked with one of the 2 xtals on board (with the correct value)

Regarding under/over run yes that's possible, but we calculated the file has to play continuously for a few hours before it can happen. In that particular case the buffer will be reset to initial condition (about 0.7s )
Otherwise as soon as a gap is detected (between songs) the fpga will reset the buffer.

This shield its meant to work only with SBCs i2s RPI connectors , so no USB/SPDIF for the moment

Maybe cheaper solutions:
1/
From TI PCM1542:
"...improved tolerance to clock jitter."
=> Use a modern DAC to reduce clock jitter

2/
HIFIBERRY DAC+ PRO has 2 clocks working in master mode, and the driver select the clock for 44.4khz or 48khz samples.

Problem is for each solution, there is no measurement => No way to say: 1/ If it reduce the jitter (The clock speed of the raspberry is not the single issue : Raspberry pi has a poor bandwidth, shared with other components) 2/ Which one is the best

Maybe can you be the first to provide measurements?
Another question I have, If we need a reclocker, What is the advantage to use I2S vs USB ??
 
Last edited:
1. Even a very modern DAC such as ESS Sabre will still gain from a low jitter clock. Any DAC will gain from a good clock..a better clocks (low phase noise/jitter) always provides better analog conversion. "...improved tolerance to clock jitter."...that's just some marketing bs.

2. Yes that's an excellent way of solving the problem...except :
a. clocks themselves are driven from 3.3v taken from RPI (that will give the local clocks a lot of jitter) . Even one LDO (to drive the clocks) is insufficient...some people use shunt regulators .
b. by using a reclocker you effectively remove the "kernel/os" from the equation. The reclocker becomes an RTOS and DATA(buffered) + clocks are feed directly to DAC (no interrupts or bandwidth problem) . Think about your RPI as being just a front end ...and the music (data + clocks) are running on a different CPU using real time OS.
Yes we will post the measurements from oscilloscope ...we got 3ps of jitter (after buffer)