New FIFO buffer for RPI/SBCs - diyAudio
Go Back   Home > Forums > Source & Line > Digital Line Level
Home Forums Rules Articles diyAudio Store Gallery Wiki Blogs Register Donations FAQ Calendar Search Today's Posts Mark Forums Read

Digital Line Level DACs, Digital Crossovers, Equalizers, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 1st August 2016, 10:23 AM   #1
diyAudio Member
 
Join Date: Jun 2015
Default New FIFO buffer for RPI/SBCs

Hi ,

in the past few months we have worked very hard on a new shield for RPIs/SBCs.

Basically the main idea belongs to Ian's. His hardware is actually superior to ours , mostly in the way he implemented the clocks and to the attention of the detail (like mounting xtals on a pcb supported by elastics ). So we credit Ian's idea and his great design.

Our hardware/soft is not a copy , its an implementation of the same idea. We use a FPGA and sram to buffer the DATA and we reclock bclk/mclk outside the FPGA using NDK (or Crystek) . The board has an eprom but its not HAT complaint (because of the space). FCC will be available for the board.

Main reason for making the board was to try to correct the audio clocks of SBCs and bring high quality audio to anyone that has an SBC around..for a great price.
Attached Images
File Type: jpg Kali1.jpg (654.3 KB, 2520 views)
  Reply With Quote
Old 1st August 2016, 01:01 PM   #2
diyAudio Member
 
steph_tsf's Avatar
 
Join Date: Mar 2008
Can you please tell in some articulated way, why you assume that the 40-pin connector of Raspberry Pi Single Board Computers (SBCs) can't deliver a high quality full duplex I2S digital audio stream?
Is it caused by some impossibility to route the Broadcom native I2S signals (LRCK, BCLK, TX, RX) to the 40-pin connector?

Is it caused by the absence of MCLK?
Please note, MCLK is not part of the I2S standard.

Is it caused by software issues?

Is it caused by the lack of proper 11.2896 MHz and 12.2880 MHz quartz?

Is it caused by the USB subsystem, demanding a fixed 48 MHz clock?
Do you assume that the 40-pin connector Raspberry Pi can't deliver a high quality full duplex I2S digital audio stream :
- when the audio is coming from mass storage?
- when the audio is coming from USB using the Isochronous audio protocol?
- when the audio is coming from USB2 using Asynchronous audio protocol?
Are there workarounds like playing the audio at a stable speed, jitter free, that's not exactly 44.1 kHz and 48 kHz?

What about playing the audio through SPDIF? What will happen in case the SPDIF speed is not exactly 44.1 kHz or 48 kHz?

You wrote that you rely on a FPGA and SRAM for buffering the audio data, to be reclocked outside the FPGA using some Ultra Low Phase Noise Quartz Oscillator.
- Does it mean that your hardware always must act as Master Audio Clock?
- If yes, how to support the USB Isochronous audio protocol?
- Can you fine tune the frequency of the Ultra Low Phase Noise Quartz Oscillator, letting operate it as VCXO?
- In case the your audio SRAM write pointer is not operating at the exact same frequency as your read pointer, will you rely on sample drop or sample repeat to avoid a buffer overflow or underrun?
What is the advantage of relying on a FPGA and SRAM, compared to relying on a SRC4382 chip like there is in the $45 MiniDSP DIGI-FP ?

Best Regards,
Steph
  Reply With Quote
Old 1st August 2016, 01:32 PM   #3
diyAudio Member
 
Join Date: Jun 2015
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
  Reply With Quote
Old 1st August 2016, 02:28 PM   #4
diyAudio Member
 
steph_tsf's Avatar
 
Join Date: Mar 2008
Quote:
Originally Posted by cdsgames View Post
This shield its meant to work only with SBCs i2s RPI connectors , so no USB/SPDIF for the moment
I was referring to USB in the scenario of having the RPI acting as sophisticated USB soundcard, capable of FIR filter equalization. You can have USB Audio Isochronous (the audio source is the audio clock source). You can have USB2 Audio Asynchronous (the audio sink - aka the soundcard - is the audio clock source).
  Reply With Quote
Old 1st August 2016, 05:02 PM   #5
diyAudio Member
 
Join Date: Jun 2015
In most scenarios the RPI will be the audio player, an app , for example Qobuz/Spotify/Pandora/LMS , will run on CPU and output will be i2s to DAC. Our reclocker will work great in this scenario

Regarding the USB , it is possible to have the above scenarios , but in case of isochronous , the 2 time domains can be too far apart and the reclocker might over/under run faster that a 'few hours". However the asynchronus mode..in that case you will have a few hours (at least) since we know exactly how far is the RPI clock (on average)

I am not sure how much processing power you need for FIR filters , but I assume that on the newer generations of SBCs there is more than enough.
  Reply With Quote
Old 1st August 2016, 05:40 PM   #6
diyAudio Member
 
analog_sa's Avatar
 
Join Date: Aug 2002
Location: Cascais
A very nice idea. How are the oscillators powered? It is a very critical part of the design and many users will appreciate the option to supply their own favourite off-board regulator, or battery power. There doesn't seem to be any kind of galvanic isolation from the SBC ground, right? I guess it is a reasonable price to pay for the simplicity of the shield.

Last edited by analog_sa; 1st August 2016 at 05:43 PM.
  Reply With Quote
Old 1st August 2016, 06:10 PM   #7
diyAudio Member
 
Join Date: Jun 2015
The oscilators (only one is active) are fed by PSU filtered by LC filter + LDO

After the LDO we have some good esr capacitors to provide clean power

Correct the ground is not isolated from SBC.

Quote:
Originally Posted by analog_sa View Post
A very nice idea. How are the oscillators powered? It is a very critical part of the design and many users will appreciate the option to supply their own favourite off-board regulator, or battery power. There doesn't seem to be any kind of galvanic isolation from the SBC ground, right? I guess it is a reasonable price to pay for the simplicity of the shield.
  Reply With Quote
Old 5th August 2016, 09:52 AM   #8
diyAudio Member
 
Join Date: Jun 2015
We have chosen a date for worldwide launch
August 26

Pricing ---cheaper than 80$ ( we are still having internal discussions)
FCC/CE approved :-)
  Reply With Quote
Old 5th August 2016, 04:55 PM   #9
diyAudio Member
 
steph_tsf's Avatar
 
Join Date: Mar 2008
For an increased selling price say $99,

1) Is it possible to hook four STA326 I2S-in Class-D power amplifiers or two TDA7801 I2S-in Class-AB power amplifiers ?

I'm thinking about two 10-pin headers conveying the following signals :
VCC
AGND
DGND
SDA
SCL
MCLK
LRCK
BCLK
I2S_OUT_A
I2S_OUT_B
Please note, the FPGA should issue four I2S lanes (with same master clocks).

2) Is it possible to hook two stereo ADCs for carrying 4-ch audio measurements ?

I'm thinking about one 10-pin header conveying the following signals :
VCC
AGND
DGND
SDA
SCL
MCLK
LRCK
BCLK
I2S_IN_A
I2S_IN_B
IMO, the 11 LEDs are a waste of real estate.
Better keep one or two of them on board as debug, and have a 14-pin header carrying the 11 LEDs signals plus VCC plus GND enabling to built front panels, also featuring a 3-pin 36 kHz infrared receiver.

Best regards,
Steph

Last edited by steph_tsf; 5th August 2016 at 05:03 PM.
  Reply With Quote
Old 5th August 2016, 06:27 PM   #10
diyAudio Member
 
Join Date: Jun 2015
I think I can see where you are going with this..

1. Yes of course its possible. Actually we are looking right now at the new generation Kali reclocker. Its not the FPGA that sends the i2s signals out (because of the high jitter inherent to fpga silicon) . The re-cloaking its done at output of FPGA using flipflops
2. How many bits of resolution ? Why 2 ics..many ADCs have 4 channels..

You are looking basically to make a digital active crossover device with microphone feedback .
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
RPi 3 ifi ipower eis PC Based 10 12th October 2016 01:28 PM
RPI: Multichannel PCM over HDMI keylimesoda PC Based 0 28th January 2016 07:55 PM
RPi B+ and ES9018K2M DAC: can't get it to work! Feddo Digital Line Level 0 18th April 2015 01:41 PM
Volumio and Rpi DAC tjaekel PC Based 1 5th February 2014 02:34 PM
Using large buffer FIFO on SPDIF fed DAC wa2ise Digital Source 8 2nd February 2006 03:43 PM


New To Site? Need Help?

All times are GMT. The time now is 05:58 PM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2017 DragonByte Technologies Ltd.
Copyright 1999-2017 diyAudio

Content Relevant URLs by vBSEO 3.3.2
Wiki