Does anyone have experience with Teensy3.1, lots of WS2812b LEDs (488) and using the Audio library to do FFT at the same time?
As soon as I declare the Audio library variables (AudioAnalyzeFFT256, AudioInputAnalog, AudioConnection, AudioMemory), only about 80 pixels get updated, the rest of the LEDs stay dark.
It definitely has something to do with interrupts, as defining FASTLED_ALLOW_INTERRUPTS 0 before the FastLED.h include corrects this issue, but then the audio analysis brings wrong and weird results.
With the much higher CPU frequency of the teensy it should be able to handle interrupts like this?
Does anyone have any insight into this?
The problem is there’s a limit to how long you can go between writing WS2811 pixels before they reset (about 5µs) - and so the audio library interrupt handler has to finish in that amount of time, other wise FastLED will punt on writing out the frame (rather than risk the corruption that would happen from the leds resetting early). If the audio library doesn’t interfere with OctoWS2811’s interrupts/dma/pins, you can, at the cost of some memory, use FastLED’s OctoWS2811 driver to hand off the led writing to the DMA subsystem, sidestepping the interrupt issue: https://github.com/FastLED/FastLED/blob/FastLED3.1/examples/Multiple/OctoWS2811Demo/OctoWS2811Demo.ino
@Daniel_Garcia If I made a similar DMA-based “MonoWS2811” library, which also worked on Teensy-LC, would you be interested in supporting it as a driver from FastLED?
Yeah - that’d probably be pretty straightforward to add in there.
Thanks @Daniel_Garcia and @PaulStoffregen , I will try with the OctoWS2811 output tonight.
Do I understand it right, that I have to declare an array of 8x[max_length_of_pixels] and only update the values I actually have pixels connected? ( I have 2x256 pixels actually connected)
Yes, you do 
Also - since you have two strands, the combination of parallelized output and the backgrounding of it will also buy you back a bunch of cpu time. Where you were spending 15.36ms per frame before, now you’ll be spending more like 2ms cpu time per frame (doing the scaling/bit rotation before handing off to DMA, comes out to about 7.8µs * leds in a single strand)
Awesome stuff! This works like a charm Thank you!
