16kHz might be a good compromise on small MCU's:
- GEQ will show frequencies up to ~6Khz
- FFT process may use up to 32millis (-> 100% CPU load). Try to stay below <60% so FreeRTOS can schedule all tasks properly.
- more CPU time is left for other WLED, so it maintains LED FPS and stays responsive on web UI.
Only run FFT when the result will be used.
Please note that this also means that `FFTTime` shown in Info is only meaningful when there is sound input and not silence.
--> To get exact FFT times, the optimization can be disabled by compiling with `-D SR_DEBUG`
I2S microphones were not working any more in with the newest framework - only delivers silence.
Ther reason is stupid bug in espressif I2S "compatibility" driver: RIGHT and LEFT channel are swapped, so when only asking for LEFT, we get silence from RIGHT.
Workaround: simply change LEFT to RIGHT, until the problem is fixed in ESP-IDF --> Fix tested on "classic ESP32", but still need to check behavior on -S3.
Code compiles also on -S3, -S2, and -C3.
smaller changes:
- a few changes to use new APIs (MCLK, rouing and sample resolution)
- a few additional debug messages
- put correct value into _pinConfig.mck_io_num
- the connected() method only get called once a Wifi STA connection is established. UDP Sound Sync should also work when sender is in AP Mode.
- added a few comments that should help to understand the code structure.
- Info Page: add a small horizontal line below usermod specific part. Improves readability.
- updated 2D mapping mode of some 1D soundreactive effects
- alllow some effects to fade slowly, even slower that possible with SEGMENT.fade_out(). Looks nice.
not sure why - most effects only fade when using SEGMENT.fade_out(), while some need SEGMENT.fadeToBlackBy().
- save 1K of RAM by optimizing out
fftBin[].
- moved several copies of the peak reset code into a single function
- moved peak detection out of getSample().
- call peak detection function as last step of FFTcode. More optimal, and we can be sure that fresh FFT result are available.
Peak detection/reset are now called from both tasks, so I had to move some peak-related vars out of AudioReactive class and make them global (static).
- put variables with same context next to each other.
- removed a few vars that are not needed any more.
- replaced "16" by a more descriptive constant
... found that stupid commit messages get more attention ;-)
- use 22050 Hz for sampling, as it is a standard frequency. I think this is the best choise.
- redesigned the GEQ channels (fftResult[]) for 22Khz, based on channels found on old HiFi equalizer equipment. 1Kzh is now at the center; Bass/Trebble channels are using 1/4 on left/right side respectively - similar to real equalizers. Looks nice :-)
- adjusted effects that use FFT_MajorPeak so that the maximum frequency is supported.
- new feature: "Input Level" (info page) can be used as global "GEQ gain" - only when AGC is ON (was already possible when AGC=off)
- some parameter tweaking in FFT function
- hidden feature: FFT decay is slower when setting a high "dynamics Limiter Fall time" (steps: <1000, <2000, <3000, >3000)
- FFT_MajorPeak default 1.0f (as log(0.0) is invalid)
- FX.cppp: ensure that fftResult[] is always used inside array bounds
- removed broken FFTResult "squelch" feature. It was completely broken, and caused flashes in GEQ.
- added Frequency scaling options: linear and logarithmic
- fixed a few numerical accidents in FX.cpp (bouncing_balls, ripplepeak, freqmap, gravfreq, waterfall)
- On/Off controls the complete feature
- Rise Time and Fall Time are the minimum times (in milliseconds) for "volume" to go from 0% to 80% and back.
- when "On" we also use some filtering to smooth FFTResults[]. Rise and Fall Times do not affect Frequency reactive effects otherwise.
* Header checking for sound sync receiver: removed wrong "!"
* make sure all member vars have initial values
* some robustness improvements in case of receiving bad UDP data.
improved ADCsample processing, including replacement of "rogue" samples from other channels (this happens at least once in 5 seconds !!).
It compiles, don't ship it yet - needs more testing.
- smoothing FFTResult (don't have a matrix to test)
- UDP sound sync improvements
- some bugfixes from SR WLED
- button.cpp: avoid starvation: strip.isUpdating() can be true for a long time.
work in progress - still needs testing!!
-new methods: getType(), isInitailized(), postProcessSample()
- allow users to compile for RIGHT audio channel (-D I2S_USE_RIGHT_CHANNEL)
- better handling in case audio input driver failed to initialize
- removed some unneeded code and unneeded parameters
UDP audio sync: introduced new header version, because the new struct (without myvals[]) is not compatible with the previous struct. Also optimized structure size.
UDP audio sync: sender decides is AGC or non-AGC samples are transmitted.
getsamples: move volumeSmth/volumeRaw code out of AGC core function.
Implemented PinManager and rerun setup of usermod after updating pins/
Registered in const.h and pin_manager.h I tried to follow the existing formatting/numbering in these files.
Wrapped any strings I could in F()
Added public variables to the BME280 usermod based on those in the Temperature usermod. Only complication is that this usermod utilises different function calls depending on whether user defines celsius or not. I have handled this for the temperature, but the Dew Point and Heat Index are relative to the temperature.
I've also addressed some areas where I'd previously assumed Celsius for reporting purposes as my test case is using Farenheit.
I added a Usermod interface for key settings. I used a PinArray for the SDA/SCL pins, but you can't name these individually.
I have also made a display to show the temperature/humidity values in the web interface's Info screen.
I had to change the definition of those items in order to allow these new functions to work. I have not noticed any negative side effects to this change.
At the moment, I've not figured out how to make Celsius/Farenheit toggleable due to the way the #define setup works.
Finally, I have added a routine to publish MQTT Discovery Topics for Home Assistant (toggleable in the Usermod screen).
I've been testing this on the only suitable device I have for a few months and haven't noticed any problems.
gain =1 does not make much senses, at it means "0.0825"; 40 internally translates to "1". 60 seems to be a good start.
- Don't use ADC analog microphone as default, to avoid well-known conflicts with other stuff hooked up onto ADC1,
- re-enabled a forgotten delay (overlooked that in my last commit)
- same fix as in SR-WLED upstream
- if strip.isupdating() is true for more than 12ms, run audio filter loop regardlessly. The userloop is very fast, so I'm expect no bad side-effects from this.
