Please note that these statements are included for clarification purposes only.
WLED-MM specific source code is always provided under GPLv3, see LICENSE.
* added ESP_INTR_FLAG_IRAM to reduce lost samples (only on ESP32 without PSRAM) --> may cause crash if used wrongly
* FFT_MajorPeak stabilized, by ignoring extreme results
zero crossing counter is often larger than in the prototype by @troyhacks - due to calculation after filtering (catches more crossings), and due to the fixed condition for detecting zero crossings (doubles the number of crossings).
This patch reduces the final value to 2/3, so it typically stays below 256.
* calculate zero crossings after filtering out DC offsets
* update effect variable only once
* fix a logic error when detecting zero crossings
* fix array bounds violation when creating umdata entries
The compiler has added gaps, to align our struct for hardware compatibility.
* made the gaps explicit
* added `__attribute__ ((packed))`, to ensure that the data layout is the same on all platforms (extensa, risc-v, 8266)
we can use `-D CONFIG_ASYNC_TCP_TASK_STACK_SIZE=xxxx` to increase the stack size of AsyncWebserver - default is 8196.
This should give us a bit of headroom for new UI items.
We still need PR #94 for more savings.
new "Receive or Local" mode:
if UDP sound is missing or interrupted for too long, switch back to local audio input.
UDP sound resumes when a fresh packet is received again.
--> still needs testing, and even more regression testing.
The standard build is sending packets each 20ms, which means there are double packets (no new FFT results yet) and the max. delay between sampling and sending is up to 50ms.
* (FASTPATH only): FFT Task directly notifies UDP send when it has new data, reducing delays to the absolute minimum. this also optimizes UDP packets throughput, by avoiding duplicates.
* (FASTPATH only): receiver polling frequency is increased, to process new packets earlier (may increase CPU load)
UDP transfers have some delays (measured between 2ms and 400ms). As consequence, FFT results sometimes "freeze" for a short time as no new data is arriving.
To hide these freezes, we apply the same "dynamics limiter" method as for volumeSmth.
Some optimizations in FASTPATH mode, to ensure that audio processing takes places as soon as new samples are arriving:
* raise fftTask prio to 4 (above async_tcp) - to ensure that other gimmicks (MQTT, IR, alexa, live preview (ws), json API, or web UI) cannot cause delays by preempting audio.
* changed the "be nice" condition in AR::loop
audioSyncPacket contains four "invisible" padding bytes added by the compiler. These need to be initialized to zero, as future versions of the protocol will make use of these fields.
