Comparing two pieces of audio on an MCU - Page 1
Forum section: electronics / general

author: Saimoun
author_rank: Frequent Contributor
timestamp: May 25, 2021, 01:17:50 pm
content: HiI am making a test board which has to test the audio output (very short audio) of a device.The audio does not have to be checked very precisely, just that the audio somehow ressemble the output.For example - I attached a picture of:* Top = samples read from the ADC on the test board (plotted on plotvar.com)* Bottom = audio played from the device (from the oscilloscope)If a human had to check, I would simply look at the two and say "yea they look similar" - that is good enough for me.My question: how can I do that check with an MCU (without using an external computer)?There are about 700 8-bit samples to process. I have:* In RAM the 700 fresh samples just recorded* In Flash memory I can have 700 pre-recorded or FFT values, etc. - anything to compare it toThank you!SimonPS: I previously asked about the setup (see here:https://www.eevblog.com/forum/beginners/basic-adc-setup-with-mcu/), and thought I would be able to simply compare sample by sample (with a threshold) between the values from the ADC and pre-recorded samples. I am not actually too far but I think it would be better with a "proper" comparison using something like FFT.

author: Saimoun
author_rank: Frequent Contributor
timestamp: May 25, 2021, 01:22:39 pm
content: I am using an STM8 MCU, and I found this code doing FFT and audio processing directly on the MCU.https://www.st.com/en/embedded-software/stsw-stm8076.htmlThinking it might be a good start?

author: sigma_xi
author_rank: Contributor
timestamp: May 25, 2021, 02:15:33 pm
content: I don't think that transforming your input to the frequency domain via FFT is going to help, since you need to compare recorded values with stored values in either case.Given that the recorded values are aligned with the stored values, i.e. you have to detect the start of the recorded audio, I suggest to take the difference and apply some kind of norm (https://en.wikipedia.org/wiki/Norm_(mathematics)). The norm can easily be compared to a threshold that you define depending on how large the error between recorded and stored audio may be.I assume it is sufficient to use a Manhattan norm, so you just compute the absolute value of each difference and sum them up. You can even do this directly within the ADC interrupt routine, so you don't have to store the recorded audio. This saves memory if you don't need the recording afterwards. A draft/pseudo code for the ADC interrupt isCode:error=0; // accumulated errori=0; // sample counterADC_interrupt(){sample=getADCvalue();diff=sample-original;error+= abs(diff);i++;}And, after all samples have been recorded you just do the comparisonCode:if(error>threshold){...}else{...}

author: sigma_xi
author_rank: Contributor
timestamp: May 25, 2021, 02:21:55 pm
content: As for the threshold, you can derive it from the average tolerance of each sample.For example, if each recorded sample may differ by +- 4 from the original value, then the threshold for the error is 700*4 = 2800. However, this does not guarantee that each sample is just +-4 off. It only ensures an average of +-4.

author: Marco
author_rank: Super Contributor
timestamp: May 25, 2021, 02:29:47 pm
content: Quote from: sigma_xi on May 25, 2021, 02:15:33 pmIf the sampling is not completely synchronous with the test signal generation, but relies on a trigger instead, and the test signal has content near 1/2 sampling rate then the FFT is an alternative to resampling. Without resampling a fractional sample misalignment from a digital trigger could make sample by sample comparison go woefully wrong.

author: fcb
author_rank: Super Contributor
timestamp: May 25, 2021, 02:36:24 pm
content: Autocorrelation, probably of an FFT.https://en.wikipedia.org/wiki/Autocorrelation

author: sigma_xi
author_rank: Contributor
timestamp: May 25, 2021, 02:41:19 pm
content: Quote from: Marco on May 25, 2021, 02:29:47 pmTrue, perhaps I am underestimating the intricacies of synchronization.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 25, 2021, 05:24:38 pm
content: Knowing what kind of features in the signals you want to compare should be "similar" would help. What are those signals?For a "generic" approach (not assuming anything about the signals to compare), one approach is to use normalized cross-correlation:https://web.psi.edu/spc_wiki/Normalized%20Cross-CorrelationBut there may be other, possibly less CPU intensive approaches, depending on the signals you have to compare.

author: Saimoun
author_rank: Frequent Contributor
timestamp: May 25, 2021, 07:42:18 pm
content: Hi allThank you very much for the replies!I thought I needed stronger tools like FFT because the signal was not as precise time-wise, it could vary from 1 to 3 samples delay.But I actually ended up using a solution similar to sigma_xi's, but comparing 5 samples (from index-2 to index+2) on the original/reference samples to take into account that the signal could be slightly moved.I had to raise the threshold for error to +/- 7 (on 8-bit values) otherwise I would get a failed result once in a while. I am checking the error for each sample though and not summing them up, so when it is valid I know my samples are on the +/- 7 rangeThank you all again - it's not the prettiest solution but it works (it also fails when it should I tested it), for a testing board i do not want to spending ages on the code (otherwise I might as well just test manually)

author: ucanel
author_rank: Regular Contributor
timestamp: May 25, 2021, 07:54:48 pm
content: This may give some idea:"how shazam works computerphile"https://youtu.be/RRsq9apr5QY

author: ledtester
author_rank: Super Contributor
timestamp: May 25, 2021, 08:10:10 pm
content: I would use test samples that consist of a single frequency. Testing that you are getting the expected frequency and amplitude is a lot simpler than comparing complex wave forms. It is also time-invariant -- i.e. it doesn't matter when you start sampling as long as you collect enough complete cycles.Have multiple test samples that span the range of frequencies you'll be working with.

author: Saimoun
author_rank: Frequent Contributor
timestamp: May 26, 2021, 08:26:00 am
content: @ledtester: yes that would be ideal but that would require changing the device under test

author: JohnnyMalaria
author_rank: Super Contributor
timestamp: May 26, 2021, 04:07:25 pm
content: Cross correlation (not autocorrelation since that is on a single signal).

author: RoGeorge
author_rank: Super Contributor
timestamp: May 26, 2021, 04:22:56 pm
content: Quote from: simonlasnier on May 25, 2021, 01:17:50 pmTrain a NN on a computer, to get a model that recognizes the expected type of signals. Then, once you have a trained model, it can be run on the MCU for inference only, to give a pass/fail check with the MCU alone.LATER EDIT:Stumbled today upon an article with a project doing exactly that:https://hackaday.com/2021/05/26/speech-recognition-on-an-arduino-nano/https://www.instructables.com/Speech-Recognition-With-an-Arduino-Nano/