search

blazoncek / WLED

Control WS2812B and many more types of digital RGB LEDs with an ESP8266 or ESP32 over WiFi!
MIT License
31 stars 0 forks source link

Volume sound effects do not work with large ledcount as strip.isUpdating() is true all the time #36

Closed ewoudwijma closed 1 year ago

ewoudwijma commented 2 years ago

Ugly workaround: remove if (!enabled || strip.isUpdating()) return; in audio_reactive.h. This works fine.

Better workaround: check with softhack007

Solution: find out the root cause why isUpdating is always true in this situation

ewoudwijma commented 2 years ago

Softhack said earlier:

sure, you basicially need this part: https://github.com/blazoncek/WLED/blob/ce32ac19dda3760fc66e742db4a69b3720e006e8/usermods/audioreactive/audio_reactive.h#L949-L961 and this line directly before getSample(): https://github.com/blazoncek/WLED/blob/audioreactive-prototype/usermods/audioreactive/audio_reactive.h#L1009 Image Image

blazoncek commented 2 years ago

If the LED count per pin is above 800 (or 650 for RGBW strips) it takes more than 24ms (the usual 42FPS) to update them all. Usual effect calculations (on ESP32) take less than 5ms to complete (even with LED count above 800) thus idling for next effect frame calculation for ~20ms. But, since the loop() (which also handles usermods.loop() runs at full speed and not idling like strip.service() does it gets attention every (usually) 0.7ms (about 1500 runs/s) so the strip.isUpdating() will often return true in such cases.

Which is good. It should prevent hogging CPU during LED updates and thus prevent flickering due to starvation of CPU resources for interrupt routines.

The solution that @softhack007 presented (by waiting at most 12ms until forcing loop() execution) may be an adequate solution to minimise flickering while still allowing usermod to run on regular terms.

blazoncek commented 1 year ago

Closing as per above.