Teensy 4.0 I2S MIC Breaks FastLED

Status
Not open for further replies.

MSO

Active member
Hello everyone! I have finally been able to assemble all my components for my LED project. It consists of:
1. Teensy 4.0
2. 1680 WS2813 LEDs
3. SPH0645LM4H-B breakout microphone
4. HC-05 Bluetooth
5. Passives, level shifter, and minor sensors.

The objective has been to display various patterns on the LED matrix (28*60), and to visualize music. The display works pretty well for displaying patterns, and my FFT code provides data to the serial monitor just as I expect it to. However, when I try to add the audio component with LED writeout the LEDs provide garbled output, even without calling any of the audio functions. It seems the act of including the 'AudioConnection' to the I2S mic is what breaks functionality. I have looked around the forms, and I haven't seen anyone describing the same problem.

Here are some of the main things I have tried:
1. Reducing the number of LEDs the program writes to, no effect
2. Reducing the number of parallel outputs the program writes to, no effect
3. Grossly simplifying the program, no effect
4. Changing the LED write frequency, no effect
5. #define FASTLED_ALLOW_INTERRUPTS 0, which throws an error: View attachment error.txt
6. Substituting the I2S mic for an ADC, this doesn't generate the error, but this is not a good workaround, as the ADC mic has its own suite of problems
7. Removing/adding the mixer
8. Commenting out the 'AudioConnection' will preserve FastLED output, but obviously this kills audio

I think it might be some sort of timing problem, but I am surprised that it kills FastLED functionality without even calling a function. This one is definitely at the limits of my understanding, and I would really appreciate any help, or potential options to test on the code that I have been using View attachment Audio_Simplified___lights_test_cutdown.ino. Thanks a bunch for any help you can provide.
 
If you set up an AudioConnection to an input or output device the Audio system flies into action there and then,
basically the first hardware audio component that has something useful to do initiates the Audio subsystem.

Thus creating the AudioConnection is the point in time Audio-related interrupts are likely to start happening,
every 2.9ms.

The underlying issue is likely interrupt related, I don't know anything about FASTLED though, it may disable
interrupts for too long perhaps?

Hope this helps find a workaround.
 
That makes sense. I'm just a little bit confused that it seems to break output even when FastLED is only writing one light. It break output even if it only writes to that light once every second, that's the tricky part. I'll have to look more at solutions for the FASTLED_ALLOW_INTERRUPTS 0, but I feel like there must be something else. Thanks for the help!
 
That makes sense. I'm just a little bit confused that it seems to break output even when FastLED is only writing one light. It break output even if it only writes to that light once every second, that's the tricky part. I'll have to look more at solutions for the FASTLED_ALLOW_INTERRUPTS 0, but I feel like there must be something else. Thanks for the help!

Hey, try including the OCTOWS2811 library, and you won't have to change much else in the code. However, this sets the output pins, which you can find on the PJRC page about OCTOWS2811, starting with pin 2. It has worked for me in the past, let me know if this helps. Good luck!

#include <OctoWS2811.h>

#define NUM_STRIPS 3

CRGB leds[NUM_STRIPS * NUM_LEDS_PER_STRIP];

in setup():
LEDS.addLeds<OCTOWS2811>(leds, NUM_LEDS_PER_STRIP);
 
Thanks for the reply. I went back into the sketch to add Octo and I found some interesting when I removed the delay normally necessary to write LEDs on the 4.0. It's very finicky, but I might be able to make something happen there. I'll update you if I find anything new.
 
Hi,

I haven't yet used a Teensy 4, nor an I2S microphone, however, I have spent a lot of time debugging FastLED with audio library issues on Teensy 3.

WS2813's (and family) have very strict timing requirements. In the normal running, FastLED will release control of the processor in between transitions; but if the duration of an interrupt that happens in that time, exceeds the length of time before the next transition, FastLED doesn't get control back in time, and misses the timing for the LED - resulting in all sorts of issues.

In this instance, the audio library ticks are likely resulting in mistiming of the LEDs.

FastLED provides a means to disable interrupts between these transitions; there's a #define FASTLED_ALLOW_INTERRUPTS or words to that effect. However; in your instance, with the number of LEDs you are driving, this won't be feasible, as you will almost certainly miss audio data during the LED updates.

OCTOWS2811 is almost certainly the best answer here; FastLED is a beautiful library, but the nature of the interrupt driven implementation creates a lot of problems for compatibility with other libraries that need tight timing control (eg, Audio).
 
Thanks for your reply! You're very right. I think for this type of application the SPI chipsets are absolutely the way to go. In this case, I don't really need high precision, so I was hoping to eek out some rough audio data. However, as you said, the strict timing requirements of clockless chips require another solution. The thing that is a bit strange is that I can do FFT with a basic arduinoFFT library, and it does not interfere with lights, but not the Teensy audio library. That's what really made me search of a solution in the Teensy audio library.
 
Status
Not open for further replies.
Back
Top