A (mostly) working demo of OctoWS2811 + audio adapter

Not open for further replies.


Well-known member
Here's my first circuit to test the Teensy audio adapter's microphone capabilities.

The audio adapter has a generic electret microphone (I think it's 'KEB6550PF' from http://www.futurlec.com/Microphones.shtml) and connects to the Teensy via the SGTL5000 pins (9,11,13,18,19,22,23).

The LEDs are connected via a 74HCT245 and 100 Ohm resistors per the OctoWS2811 library.


Like others, I had problems getting the OctoWS2811 and Audio libraries to play nice with each other -- either the code would lock up in setup() or I'd never get any data from myFFT.available(). I tried redownloading the latest versions of the libraries from github and recompiling but no luck; finally I found I'd been putting my (newer) copies in my Documents/Arduino/libraries dir but there was still an older copy of WS2811 in the Arduino program folder (C:/Program Files/Arduino/libraries in Windows) that Teensyduino installed. Deleting that old version fixed things.

Here's what it looks like:

My code is based on the Audio library's SpectrumAnalyzer example but I used fewer FFT bins for the left LED bars (lower frequency) and more for the right bars (higher frequency) because it looked better than the example's linear distribution.

I say "mostly" working in my title because it's still a little glitchy. Here's some examples of what happens at random intervals (sometimes several times per second, sometimes a few seconds between glitches, never consistently).


If I run the OctoWS2811 examples, or if use my program but comment out all the audio code and use random data instead of FFT samples there's never any glitching.

There also isn't any glitching if I comment out just the audio output lines e.g.

//AudioOutputI2S      audioOutput;        // audio shield: headphones & line-out
// Create Audio connections between the components
//AudioConnection c1(audioInput, 0, audioOutput, 0);
AudioConnection c2(audioInput, 0, myFFT, 0);
//AudioConnection c3(audioInput, 1, audioOutput, 1);

but then the FFT analyzer stops working, which is consistent with this thread:


There's another thread with comments from Paul that Teensy+OctoWS2811+Audio adapter should work, but with others having flickering issues here:


Unless I'm reading wrong it looks like Paul's only using the Audio output and no input, so maybe it works for him because there's no I2S audio read? I'm speculating but maybe it's an intermittent problem where once in a while the trifecta of I2S audio read + OctoWS2811 DMA + I2S audio write step on each other and glitch?. I will keep working on it.

For completeness I'm posing my code; I apologize for the unreadability of it.
View attachment EQTest.ino
Nice work =)

I had a problem where it wouldnt take audio in, but that was because I left some pins connected between the octo board and audio, so after those were snipped it was fine.

*edit*just read your reply.... but for others!
Im using the fastLED library and some patterns from funkboxing ( which I highly recomened. Its not as effecient/fast as the octo library im fairly, sure, but im not getting any flickering.

Last edited:
Hi, is there any change someone here is able to shed some light on how the number of bins in each band are calculated in the following code ?

int fftBuckets[NUM_COLS+1] = {0,1,2,3,4,5,6,7,8,9,10,11,17,26,37,52,71,97,128};

My best approximation for the the above is:
1 ,1, 1, 1, 1, 1, 2, 3, 4, 8, 9, 14, 18, 27, 37, 54, 74, 107, 148

I've plotted the frequencies of these values against mine and against what I understand would be the Octave frequencies graph:
PS: I'm using frequencies up to 22050 because I am using a 1024 FFT.

I've also found the following numbers in the SpectrumAnalyzer.ino example, but I can understand how to calculate them either.

int frequencyBinsHorizontal[matrix_width] = {
   1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
   2,  2,  2,  2,  2,  2,  2,  2,  2,  3,
   3,  3,  3,  3,  4,  4,  4,  4,  4,  5,
   5,  5,  6,  6,  6,  7,  7,  7,  8,  8,
   9,  9, 10, 10, 11, 12, 12, 13, 14, 15,
  15, 16, 17, 18, 19, 20, 22, 23, 24, 25
Last edited:
The horizontal scale should in general be logarithmic (not necessarely per octave, any base will do). But for these kind of limited resolution displays, a lot of times, the bottom end is stretched, both due to limited number of bins, but also because more interesting stuff (visually) is happening at the bottom end of the spectrum.
In your excel plots, try to set the vertical scale to logarithmic.
Hi kpc, Here's an excel plot of the values in EQTEST.ino on a logarithmic scale against the octave values.

It seems as if 2 different functions are used to calculate these values. Or maybe they are hand picked ??
Not open for further replies.