Teensy Super Audio Board

Professional quality, 24 bit, 192kHz audio breakout board for Teensy 3.x, Raspberry Pi, and more.

Similar projects worth following
Professional quality audio breakout board, mainly targeted towards Teensy 3.x and Raspberry Pi 2, but also should be compatible with any boards having an I2S and I2C interface broken out (FPGA boards with enough GPIO included).

The hardware design is open sourced under Creative Commons CC-BY-SA-NC v4.0 license.

Accompanying software has different licenses depending on the location; the linux kernel drivers for the Raspberry Pi are under the GPL v2 license to match other kernel drivers, and the Teensy proof of concept (sine test) code and other Teensy additions are under the MIT license (see individual source code for details).

I decided to do this project because I had been playing with PJRC's own audio board, but a lot of people on the forums had been asking about higher quality audio, and I thought it sounded like a fun design challenge.

I started the design by choosing the audio codec. The best one that I could find for a moderate price and in a package conducive to hand soldering (ie, no QFN, BGA, etc) was the Cirrus CS4272.

The CS4272 is a really high quality codec. It can do sample rates up to 192kHz at a bit depth of 24 bits. It's banner specs are a THD+N of -100dB and a dynamic range of -114dB. It is an ideal choice for a professional quality sound board.

One issue with the CS4272 is that it doesn't include the analog input and output buffers that are commonly integrated into lower quality audio codecs. This necessitates a lot of additional external circuitry that must be carefully designed to avoid compromising the audio quality of the codec itself.

Another big design constraint was to keep the Teensy side of the board fully isolated from the codec to prevent ground loops when audio equipment is connected to the device.

Here's a quick design overview:

  • Power supplies:
    • There is a switch mode supply to generate +5.7V for the LDOs
      • Can accept +3V to +7V (designed for 4xAA batteries or USB power)
    • There are 2 LDOs to generate the final, clean +3.3V digital, and +5V analog supplies
    • There is a lot of filtering between the switching supply and LDOs to minimize noise on the final supply lines
  • Digital interface
    • The Teensy is connected to the CS4272 through a pair of digital isolator ICs
    • 2 interfaces
      • I2C for control
      • I2S for data
      • and a reset pin (GPIO on teensy)
    • The isolators have ~50 ohm source and receiver impedance, so there are source terminations added to the codec outputs
  • Codec
    • CS4272
    • 24.576MHz crystal
      • Allows CS4272 to be I2S interface master
      • Minimize interface jitter
  • Audio output buffers
    • THS4521 fully differential opamp (really good specs)
    • 3rd order bessel filter
      • <0.5dB rolloff to 20kHz
    • MFB topology
    • Fully differential output
      • Capacitively coupled with 100uF electrolytic caps
  • Audio input buffers
    • THS4521 fully differential opamps
    • Topology optimized for driving 2.7nF input capacitor
    • Input impedance is somewhat low at 1k Ohm
      • Impedances optimized for THS4521 performance
      • Could increase impedances, but worse noise, distortion
    • Fully differential inputs
      • Capacitively coupled with 100uF electrolytic caps

The testing I've done so far shows that the board is performing very well. I don't have any test equipment or audio gear that's good enough to do real testing, so I've been looping back the board's outputs to its inputs, and measuring the performance that way. The only downside is that there is no way to separate the output response from the input response, but the individual responses should be better than the overall loopback response.

Here are some plots of the testing results, along with the measured performance specs:

THD+N of left channel loopback measured at -98.6dB

Dynamic range of left channel loopback is 107dB

~130dB of isolation between left and right channels

Flatness better than 0.5dB 20Hz to 20kHz (48kHz sample rate)

Frequency response with 192kHz sample rate (-6dB rolloff at 65kHz)

Update 6-7-15: Ran a 48kHz THD+N test using the output and input single-ended. Results look pretty good, the THD+N degraded <5dB:

Design and build thread at Teensy forums: Forum Link

  • 1 × Cirrus CS4272 Audio Codec IC
  • 4 × TI THS4521 Fully differential amplifier
  • 1 × Linear LTC3534 Switching power supply
  • 2 × Linear LT1962 Linear regs
  • 1 × TI OPA2348 Common mode voltage buffer

View all 7 components

  • Official Raspberry Pi Support

    RF William Hollender02/27/2018 at 17:19 0 comments

    Support for the SuperAudioBoard has been accepted into the official Raspberry Pi kernel fork, and is now included as part of the bleeding edge 'rpi-update' release.  It will eventually be included in the official Raspbian image, but I don't know the timing of these releases.

    Configuring a Raspberry Pi to work with the SuperAudioBoard is now as simple as updating the latest image of Raspbian using the 'rpi-update' command, and making some changes to the /boot/config.txt (see the user guide for details).

  • Don't always trust the datasheet (sample rate bug fix)

    RF William Hollender09/30/2016 at 04:28 0 comments

    TLDR: All of the code for the SAB using either the Teensy or FPGA as a controller had mistakenly set the sample rate to 32kHz instead of 48kHz due to an inaccuracy in the datasheet. The code in github has been fixed so that the sample rate is correct.


    I was recently trying to help someone who had built a board up, but couldn't seem to get the correct frequency output. They were trying to simply output a 1kHz sine wave using the Teensy Audio library. Everything seemed to be working, but the output was at 667Hz instead of 1kHz. The sample rate seemed to be at 32kHz instead of 48kHz for some reason.

    The CS4272 codec has a number of different modes, I designed the board to use a 24.576MHz crystal, and only operate in master mode, where the codec generates all the clocks used for the I2S interface, including the sample rate (corresponding with the frame clock or L/R clock). The odd thing is, the datasheet only specifies 2 possible divide ratios for the sample rate in this configuration, 256 and 512, and 512 results in a valid sample rate in the 'single speed mode':

    I chose a divide ratio of 512 for a sample rate of 48kHz (256 would result in a sample rate of 96kHz, which isn't valid for the single speed mode, so only works with lower crystal frequencies). The Ratio1 bit is clearly defined for this case, but the Ratio0 bit is a 'don't care' so I wrote the code to write '11' to this field, just in case there happened to be an issue with bit ordering.

    The codec has a second mode, where there is no external crystal, and it is configured to receive MCLK, the master clock in the I2S interface, instead of generating it from the crystal. In this configuration, the Ratio bits are slightly different:

    Notice in this table, that setting the Ratio bits to '11' results in a divide ratio of 768, which results in a sample rate of 32kHz if the master clock is 24.768MHz.

    This seemed to point to a startup issue causing the codec to start in the wrong mode. This is really curious because the MCLK pin on the codec is supposed to be an input in this configuration, but then there wouldn't be anything driving the pin at all. I thought that maybe this problem was a one off board problem, and that some interference between the clock oscillator and MCLK pin was causing a startup issue.

    After much troubleshooting, however, it turns out that all the boards have this problem, even the ones that I've done all the performance testing on. Oops!

    I hadn't ever seen the problem before because I had only been performing loopback testing, so all the results looked fine. I had played a sine wave out of a speaker, but hadn't noticed that the output was at way too low of a frequency.

    I had played music through it using the Raspberry Pi, but the part of the kernel driver that sets the divide ratio already existed (written for the CS4271, which has a compatible register set), so it actually worked at the correct sample rate.

    I never thought to go back and double check the sample rate because I don't have good enough equipment to measure the performance I was trying to achieve, and, more importantly, the datasheet indicated that any other sample rates were effectively impossible in the configuration used.

    I triple checked the startup sequence used, but it also matches the datasheet to a T. It just looks like the codec's behavior doesn't match the datasheet in this configuration.

    Luckily, it is an easy fix to get the correct sample rate. The correction is just to follow the second table, and set the divide ratio bits to '10' instead of '11'. Needless to say, all of the code in github has been updated to set the correct sample rate.

    Unfortunately, this means that all the performance data that I had collected was at a sample rate of 32kHz instead of 48kHz, and the tones used were at 667Hz instead of 1kHz. I had run a THD+N test using the Raspberry Pi which would have used...

    Read more »

  • FPGA example code now available

    RF William Hollender06/27/2016 at 05:50 0 comments

    I haven't had a lot of time to dedicate to this project recently. A few months ago, however, I finished some HDL and C to get the SuperAudioBoard working with my Spartan 6 Microboard FPGA dev kit. I just never got around to actually putting the code up until now.

    If you check the github repo, you'll see a new folder called S6MicroBoard_PoC. This has all the HDL and C needed to get the SuperAudioBoard working with this particular FPGA board, along with instructions to get started using Xilinx ISE 14.7 and the Xilinx SDK.

    The files include some pretty simple I2C and I2S interfaces that I built from scratch, and the overall FPGA image also includes a microblaze microprocessor system core to handle initializing the CS4272 and send and receive audio data.

    The I2S and I2C modules are meant to interface with the microblaze MCS interface bus, which is a very simple bus, so these modules should be easy to extend to other bus types for use in other FPGAs or applications.

    The code is pretty specific to the Xilinx platform, but could probably be easily modified to work on any other soft core.

  • Better Raspberry Pi Support

    RF William Hollender10/29/2015 at 04:43 0 comments

    After all the last minute soldering and testing just before the Hackaday best product semifinals deadline, I was ready for a bit of a break. Things got busy at home and at work, and I haven't done hardly anything on the SuperAudioBoard for 2 months!

    In the mean time, I had received a batch of the pi->SAB adapter boards and soldered them up, but hadn't tested them. A few days ago, I got a few hours to actually try them out. The boards are working great, but I still had a few bugs left over in the SAB kernel driver for the Pi.

    The new adapter boards in action:

    One of the issues that I had earlier with the Raspberry Pi was that I couldn't get files with sample rates other than 48kHz/96kHz/192kHz to play. Most consumer audio (mp3s, etc) have a rate of 44.1kHz, so this was a pretty big downside.

    It turns out that I was missing a bit of code in the kernel driver that constrained the available sample rates to the ones that are actually achievable with the SAB hardware setup. There doesn't seem to be much documentation on the kernel sound support, so finding out exactly what was needed was quite an ordeal.

    Anyway, with the additional code in place, the SAB works really nicely with the Raspberry Pi. There are a million different ways to get audio setup under Linux, but with the driver fixed, things worked well right out of the box. The only third party tool that I installed on top of the base Raspbian distro was pulseaudio, which tends to make dealing with different sample rates and bit depths more seamless than just using the basic ALSA playback methods.

    Here are a couple screenshots showing the board in action:

    The first shows the SAB recognized, and its sample rate and bit depth capabilities:

    Next there's the stream info (48kHz @ 16 bits) while playing back an online stream of a local radio station:

    And, finally, playing back a test mp3 with pulseaudio (resampling from 44.1kHz to 48kHz):

  • Teensy Audio library working

    RF William Hollender09/09/2015 at 15:39 0 comments

    After debugging some really odd behavior, I finally got the SuperAudioBoard working with the Teensy Audio library!

    The Audio library additions are in my fork of Paul's github repo here in the "SuperAudioBoard" branch. Keep in mind that the additions are still in a beta stage until they get added to the official library so some things might change (class names, etc).

    There are a couple of example sketches in the SuperAudioBoard repo that I'm using to test out the library additions.

    I haven't had a chance to test out all the control methods (volume, muting, etc), but the base setup is working well.

    Edit: I forgot to mention that there is a slight gotcha when using the Teensy Audio Library with the SuperAudioBoard: the Audio library defines it's sample rate at 44.1kHz, and all Audio library objects use that as the sample rate, but the SuperAudioBoard operates in master mode, and doesn't support 44.1kHz. The closest sample rate the SAB can support is 48kHz, so all code that uses the SAB and the audio library needs to take the sample rate difference into account when setting or reading frequencies. Check out the example sketches for details.

  • Got last proto working

    RF William Hollender09/02/2015 at 06:03 0 comments

    I've spent the last week or so taking a break since I found out that the project didn't make it past the first round of the Hackaday prize. It would have been fun to keep going, but it means a lot less stress :)

    I finally got around to trying out the SMD removal kit that I got from Adafruit, and it worked awesome! It hardly took any time at all to get the CS4272 off the board and replace it with a new one:

    The two ICs in the bottom of the picture are the two that I removed to try to fix the board after it didn't work. The smaller IC is the I2C isolator that I mangled with a diagonal cutters to separate the pins so that I could remove them one at a time. The other is the codec that I removed using the chipquik kit and it was way easier (and I didn't almost destroy one of the pads).

    It's a little annoying to replace $12 worth of components because I forgot to load 4 pull up resistors worth a total of around 0.03, but that's what happens when you rush, I guess.

    On another note, now that the Hackaday contest is over, I can focus on getting the board production ready, and getting a kickstarter going. Here are a couple of goals for the next month or so:

    1. Finish integration into the Teensy Audio Library
      1. Should go a lot faster now that I have a working prototype
    2. Test out the Raspberry Pi adapter boards that I sent out to OSHPark a few weeks back
      1. They should be arriving soon
    3. Find a more user friendly software setup for the Raspberry Pi
      1. Instructions for auto-resampling, resampling quality settings, etc
    4. Make some changes to the board for better usability
      1. Use solderable jumper pads for configuration instead of 0-ohm jumpers
      2. Lengthen pads for power supply ICs
      3. Change hole sizes for header pins and make sure that the pins are all on a 0.1" grid

    Hopefully I should be able to get everything done soon and should have a kickstarter going in a month or two!

  • Some quick updates

    RF William Hollender08/20/2015 at 05:06 0 comments

    I put together a quick interface board for the Raspberry Pi so that I don't have to use a bunch of single wires next time I want to connect it up.

    The design is really simple, but I went with a 4 layer board because there were too many signal crossings, and it meant that I could at least make an effort to keep the higher speed I2S bus lines at close to 50 ohm impedances. The boards are off to OSHPark, and I've put them on the SuperAudioBoard GitHub repo. I'll share the design on OSHPark when I've had a chance to test it (if you use the files on github, it's at your own risk :)).

    I also updated the design and user guides with some info that I had forgotten. In my haste, I had forgotten things like

    • the fact that the I2S bus isolators are unidirectional so the codec always has to be the I2S bus master (this is the best performance anyway because the clocks will be derived directly from the 24.576MHz crystal).
    • that the audio outputs are line out only, and cannot be used to drive headphones or speakers
    • the max signal swings of the audio inputs and outputs

    I'm still working on getting my last prototype working. I'm pretty sure that I've narrowed it down to the codec chip itself. I already replaced the I2C isolator, but that didn't help at all.

    I almost pulled off a pad when I replaced the I2C isolator, and it only has 8 pins, so I wasn't looking forward to trying to remove the 28 pin codec without a hot air reflow station. I was looking through Adafruit's website to see how the reflow station was priced, and I ran across this: Chip Quik SMD Removal Kit. It looks like it should be a great help. Anyone else have experience with that stuff?

  • Down to the wire

    RF William Hollender08/17/2015 at 17:50 0 comments

    It's the morning of the first Hackaday prize deadline, and I made it!

    Here's a quick recap of the last week:

    • Finished soldering three more prototypes
      • 2 of the three worked fine
      • 1 of the boards isn't working (won't communicate over I2C)
        • I think that this is because I powered the board up without pull-up resistors on the I2C lines
        • I've replaced the I2C isolator IC, but still not working
        • Next step is to replace the codec, but this will be really difficult without a hot air reflow station
    • Shipped my only three working prototypes to Hackaday
      • My first prototype and the two new working prototypes
    • My wife helped me complete the two required videos
      • The "Semifinals" video is here: video
      • The "Quarterfinals" video is linked in an earlier post
    • Made a mockup of the product packaging (again, big thanks to my wife for her help!)
    • Added a detailed design guide: link
    • And, added a user guide (still a work in progress): link

    One thing that I had hoped to finish before this deadline was to integrate the SuperAudioBoard with the Teensy Audio Library, but I had to pause work on it to finish the contest requirements.

    Here are my goals for the next few weeks before the final best product deadline:

    1. Fix my last prototype!
      1. It'll be hard to get much testing done without a working proto type :)
    2. Finish integration with the Teensy Audio Library
      1. Just a 16 bit mode to start with (24 bit support requires extensive rework of the entire library).
    3. Update the board design with some usability enhancements
      1. Address some solderability issues
      2. Better annotations
      3. etc
    4. Design some interface boards for the Raspberry Pi
      1. Better than point to point wiring
    5. Try Raspberry Pi with other audio distributions for better ease of use
      1. Working with audio in Raspbian wasn't the easiest.

    Stay tuned for more updates!

  • Product packaging and artwork

    RF William Hollender08/17/2015 at 01:34 0 comments

    My wife put together some logos and packaging ideas today. Check out how the final product might look:



  • Protos delivered and first video on youtube

    RF William Hollender08/15/2015 at 05:03 0 comments

    Got delivery confirmation on the three protos sent to Hackaday:

    And, the quarterfinals video is up on youtube:

    Big thanks to my wife for doing all the videography (and all the good pictures, too)!

View all 16 project logs

Enjoy this project?



spambake wrote 02/21/2018 at 19:11 point

I see you are putting the overlay for this project into the Raspbian distribution and that it is available for testing via rpi-update.  Keep up the good work and keep us posted!

  Are you sure? yes | no

ben biles wrote 12/24/2016 at 03:56 point

amazing project , did'nt know about digital issolators. going to use some kind of issolators on my dsp mixers I2C bus now I know they exist :)

  Are you sure? yes | no

Robert Manzke wrote 10/10/2015 at 10:58 point

Hi there, have rebuild your board twice, performance is ok, but THD a little lower (-90dB, using galvanic decoupling). I had the boards made with dirtypcbs, which was a little cheaper without ENIG finish (still have some left if anyone needs one in Europe).  

All in all a great project! Thanks to William for this!



  Are you sure? yes | no

RF William Hollender wrote 10/11/2015 at 16:31 point

Hmmm, that's curious.  All the boards that I've made have been at least 98dB.  

Out of curiosity, how are you measuring THD+N?

When you say galvanic decoupling, are you putting audio transformers on the outputs/inputs?

I wouldn't think that a different board house would make much of a difference on the performance.


  Are you sure? yes | no

Robert Manzke wrote 10/12/2015 at 06:39 point

With decoupling I referred to the Silicon Labs digital isolators (not sure if they offer really galvanic decoupling in the sense one would get e.g. with opto-couplers). We built one board without them just using zero ohm resistors, that had a bit worse THD.

For the THD+N I used the demo source from the Git repository and ran Matlab's thd function on the data. One can specify the number of harmonics to be included, we just used default.


  Are you sure? yes | no

Thomas wrote 08/06/2015 at 20:21 point

awesome, would like to create a low budget sound measurement device.  Rpi and this board, attaching a class I microphone from Brule kjaer.  This board will be perfect 

  Are you sure? yes | no

RF William Hollender wrote 08/06/2015 at 20:36 point

Sounds like a cool project.  I hope to get some adapter boards designed up for the Rpi, so that it's not point to point wiring like the picture I have up. I won't be able to get to it until after the first hackaday prize deadline, though.

  Are you sure? yes | no

Katie Fortunato wrote 07/28/2015 at 00:07 point

I need this. :D

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates