Comments (24)
I narrowed it down!
An integer overflow happens in the postProcessSample() method in audio_source.h.
If I do this:
`
// line 362
// Store samples in sample buffer and update DC offset
for (int i = 0; i < num_samples; i++) {
newSamples[i] = postProcessSample(newSamples[i]); // perform postprocessing (needed for ADC samples)
newSamples[i] = newSamples[i] + 33554431; // HERE THIS I MEAN!!
// Serial.println(newSamples[i]);
float currSample = 0.0f;
`
it's fixed!
postProcessSample mostly returned -33554431, except when yelling into the mic, then it got closer to 0.
Now it's zeroed in at zero, with positive bursts.
Now WLED appears to be a bit crashy, though, sometimes everything just freezes.
Will spend a few more hours tomorrow to find what's actually causing the overflow.
Weird that I appear to be the only one with this issue!
from wled.
Errm .... I have to look into this. Your fix does not seems right though, because there should be no possibility for overflows.
postProcessSample() does a conversion from unsigned long to signed long, and filters out some rogue samples (the ADC unit sometimes injects them erroneously). What looks like an overflow to you could simply be the conversion process from unsigned to signed, which may look like an overflow when the signal goes from positive to negative.
Edit: your magic number is actually around 512 * 65536, whis is in line with the mic_real value you see. -512 is not a big problem (adc samples go from -2048 to +2047 -512 to 511 after conversion to signed), it just means that your mic has a bad negative DC offset but the software can adapt to that.
from wled.
Audiosource getsamples works on 32bit samples, which are basically "blown up" by 16bit and later scaled down by 18bit.
To simplify debugging, you could compile with -D I2S_USE_16BIT_SAMPLES
added to your build_flags. This will skip the "blowing up" part, however reduces sample quality by 2 bits.
from wled.
You could also try this patch, which adds a very had reset procedure (bitbanging hw registers) at the beginning of I2SAdcSource::initialize
https://github.com/atuline/WLED/pull/257/files
The code between SR fork and MM fork is very similar,
So you can basically add the few includes and the register write sequence into audio_source.h.
Please let me know if this helps.
from wled.
Another possibility could be to add -D I2S_GRAB_ADC1_COMPLETELY
into your build flags. This will switch from one-time to continuous sampling, however will case a lock-up if analogRead() is used anywhere else in WLED.
Please also inform me in case this helps.
from wled.
Thanks for your input!
I tried the 16bit, the output of the println after postProcessing is now at mostly -511, when I yell it gets closer to zero.
The animations don't work, though.
I tried the pull request and added it in the initialize method of I2SAdcSource.
No change.
I've been using -D I2S_GRAB_ADC1_COMPLETELY
since about half of my debugging session. Didn't help.
By the way, if I println before postProcessing, I mostly got "1879048192"
After the 16bit change I'm getting 28672.
So to summarize: as I notice, it only seems to work if the "quiet" value is around 0 after postprocessing, or am I misunderstanding something?
edit: if I try to adjust the 1879048192 before postProcessing, after postProcessing the values is again far away from zero, so the animations don't work.
I'm not sure if my weird workarounds help in any way ;D
from wled.
So to summarize: as I notice, it only seems to work if the "quiet" value is around 0 after postprocessing, or am I misunderstanding something?
Thanks for the testing and report, this information is actually very helpful because we regularly have people who cannot get analog input to work properly. So if we find something with your setup, it might also solve problems that other people see.
Honestly, If you have a few bucks left in your wallet, the best solution is to buy an I2S digital device like the IMNP441, and leave all the analog trouble behind...
To your question: Actually its not necessary to have "quiet" at 0. In fact, you could try to comment out the post processing line, it should even work without it (but needs more time - about 30-60 seconds - to adjust filters).
There are two things you might check:
- To verify that the problem is not in the post processing code, comment out that line temporarily.
- As simple electrical test to verify that analog I2S-ADC works, replace the microphone by a potentiometer (around 10kOhm) that works as voltage divider. When you turn it, you should see that the "micdatareal" plot follows (maybe turning direction a 0, as we use absolute values at some point of the processing)
This is actually how I test the code to ensure that all possible samples are treated well. - Please check which values you get with the simple analogread() sketch, as you should see similar (but divided by 4) values in WLED. If analogread is ~0 at silence, it means that the mic signal is not centered at 1.8V so the "negative" parts of the waveform will be dropped. That leads exactly to the symptoms you observed, like input appears to be stuck at -511, and animations do not react.
Also I just committed a small change (see 42cc302) that enables a new filtering method which possibly can handle your negative DC offset better. Please try. Only downside is that the "potentiometer test" (point 1 above) will not work anymore when the new filter is activated.
from wled.
By the way, if I println before postProcessing, I mostly got "1879048192"
After the 16bit change I'm getting 28672.
This is expected - I2S-ADC samples have the channel number encoded in the high 4 bits, which is 28672 as you use ADC channel 7.
from wled.
AnalogRead is indeed around 0.
I tried
// i2s config for using the internal ADC
i2s_config_t adcI2SConfig = {
.mode = (i2s_mode_t)(I2S_MODE_MASTER | I2S_MODE_RX | I2S_MODE_ADC_BUILT_IN),
.sample_rate = 44100,
.bits_per_sample = I2S_BITS_PER_SAMPLE_32BIT,
.channel_format = I2S_CHANNEL_FMT_ONLY_LEFT,
.communication_format = i2s_comm_format_t(I2S_COMM_FORMAT_I2S | I2S_COMM_FORMAT_I2S_MSB),
.intr_alloc_flags = ESP_INTR_FLAG_LEVEL1,
.dma_buf_count = 8,
.dma_buf_len = 1024,
.use_apll = false,
.tx_desc_auto_clear = false,
.fixed_mclk = 0};
// i2s config for reading from left channel of I2S
i2s_config_t i2sMemsConfigLeftChannel = {
.mode = (i2s_mode_t)(I2S_MODE_MASTER | I2S_MODE_RX),
.sample_rate = 32000,
.bits_per_sample = I2S_BITS_PER_SAMPLE_32BIT,
.channel_format = I2S_CHANNEL_FMT_ONLY_LEFT,
.communication_format = i2s_comm_format_t(I2S_COMM_FORMAT_I2S),
.intr_alloc_flags = ESP_INTR_FLAG_LEVEL1,
.dma_buf_count = 8,
.dma_buf_len = 1024,
.use_apll = false,
.tx_desc_auto_clear = false,
.fixed_mclk = 0};
// i2s pins
i2s_pin_config_t i2sPins = {
.bck_io_num = I2S_PIN_NO_CHANGE,
.ws_io_num = I2S_PIN_NO_CHANGE,
.data_out_num = I2S_PIN_NO_CHANGE,
.data_in_num = I2S_PIN_NO_CHANGE};
for the https://github.com/atomic14/esp32_audio
i2s_sampling thingy.
This is the result: https://filebin.net/a8rb1ynt9l6xwsnp/adc.raw
Can be played with ffplay -f s32le -ar 40k -ac 1 adc.raw
Quite shitty quality.
Problem for me is that I have 240 pcs of a custom designed PCB with esp32 and analog microphone - so no choice but to make it work as-is: schematic
from wled.
I tried without postProcessing now, it does work somehow, but not a great result, visually.
from wled.
Also I just committed a small change (see 42cc302) that enables a new filtering method which possibly can handle your negative DC offset better.
Please restore postprocessing, and try with my latest commit - I think that is the best chance to get a meaningful signal out of the hardware you have.
Also "einen schรถnen Gruss" to whoever designed the pcbs. The microphone part is definitely crap.
from wled.
I just enhanced the miclogger a bit, so you can now see the real waveform. I expect that in your case, it will look like the lower part got cut away (blue line flat).
The enhanced plot looks like this (notice red+blue lines)
from wled.
Just looked at the pcb design - definitly supports my assumption. There is a capacitor that filters away any existing DC, so after the cap the signal could be like -1V ... 1V. ESP32 cannot sample negative voltages, so the part below 0V is lost, and a lot of noise is added. I think it could be repaired by adding to resistors directly before the esp pin (one to GND the other to 3.3v), to re-center the signal at +1.8v.
Not sure if ESP32 can really take negative voltages on an analog pin, without causing damage at least in long term. So be careful and cross-check the esp32 datasheet. Maybe a diode could help protect the esp pin - but that will also add another source of noise.
from wled.
oh damn.
Unfortunately, they are already at >100 customers without working sound-to-light; so I'll just have to keep my fingers crossed they won't fail.
I tried the latest commit - it works! but weirdly with about 1 second delay.
I say BLA, and the light goes on 1 second later :D
from wled.
what tool are you using to graph?
from wled.
what tool are you using to graph?
Oh that was just serial plotter from arduino IDE. You just start arduino IDE, connect the esp32 and select the right port. Then use the tools drop-down and select "serial plotter". It will draw a graphic from what the esp is sending on serial.
from wled.
Ok nice that works well.
Everytime I resume the music, it immediately shows on the graph, yet the lights go on later. If that info helps?
from wled.
I tried the latest commit - it works! but weirdly with about 1 second delay.
๐
Some delay is expected, but not that much. Could be you have to reduce the "squelch" setting (audioreactive UM) because this is the threshold where effects start to react.
from wled.
Also it might help to uncheck "sound dynamics limiter". And don't forget to switch on AGC. software AGC in audioreactive that is.
from wled.
in silence, the volumeSmoothing seems to overshoot
from wled.
Then you have to increase squelch again , until it stays flat in silence. Looks like squelch around 30-50 could work.
from wled.
ah, I hadn't touched squelch, it was at 10 the whole time.
AGC was set to vivid the whole time.
Also the delay was caused by the animation "Waterfall". It works instantly with NoiseFire :)!
Thank you for your effort, awesome work!
from wled.
Was fun, at least now I have one more idea why sometimes analog in does not work.
from wled.
Also the delay was caused by the animation "Waterfall".
I guess that all "frequency reactive" effects (1/8th note icon) will have problems, as consequence of the noise in your input.
But volume reactive effects (1/4th note) should work better.
from wled.
Related Issues (20)
- ESP32-C3 Error 19: filesystem error when connecting to Wifi network HOT 5
- Doesn't work on esp32-c3 mini HOT 2
- MM specific: random crashes when using global buffer (heap corruption) HOT 1
- Created Custom Palette Is not visible on palette list in main screen HOT 4
- Audio Responsive Custom Palette HOT 4
- The Weather usermod does not display correct temperatures plus documentation is needed HOT 1
- Loss of segment preference when changing effects HOT 2
- When creating a new preset, the entered name may be replaced by a timestamp; the preset contents may be replaced by the current state HOT 2
- Line In pass-through for ESP32 Audio Kit HOT 3
- DMX serial input isn't transmitted via sync feature HOT 1
- Individual areas flicker HOT 4
- Replace usage of millis() in effects with strip.now - sync effects across wled instances HOT 15
- ARTI-FX infinite loop due to empty renderFrame (bricks controller until reflash) HOT 2
- I2C write error for AudioSource - error message for users needed
- Mixed mode 2D / 1D works upstream but not in MM HOT 13
- Keep GFX for Matrix visible while scrolling through effects HOT 4
- Animartrix effects: weird colors in some effects HOT 15
- Moonmodules wled Segment on off not working
- Cannot rotate through Playlists via Preset. No issue rotating through other Presets via Preset HOT 3
- WLEDMM_0.14.0-b27.31_esp8266_4MB_M.bin Battery Auto Off is enabled by default HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wled.