Sound noise cancelation with two microphones

[NIquist]

What you're doing is not normal noise cancellation.  Noise cancelling headphones have the advantage of knowing in advance what the desired signal source material is.  It's the pre-recorded audio track(s) you want to hear over the outside "noise".  But that "noise" is not noise in the conventional sense of just random white or pink noise.  It's another signal full of unwanted sounds that can be analyzed rapidly and provide enough information to create an anti-sound that can be subtracted in real-time from your desired signal, ostensibly removing it.

What you are trying to do is collect two signals of the same source and then try to subtract them thinking that since one mic is closer to an offensive sound it will go away but you will probably just reverse its polarity and still hear it.  Along with a ton of processing crap.

In general, I would think that working on simply filtering the offensive content is better if you just want to hear important content, but you WILL lose fidelity and some desired content.  This will keep you working in the frequency-domain rather than the time-domain which is just easier.  Especially with your very limited hardware.

That DAQ is 12-Bit and will only (barely) handle frequencies to 10-12KHz.  Probably not even good enough to prove out your concept.  You didn't mention your mics either but although it would be easier to subtract signals if they are identical, you likely need an omni-directional model to read the room and a tight cardioid to focus on the noise source.  This is probably why you are confused by your hand clap signals.

Pretty cool project and use of LabVIEW though.  Keep us posted...

EDIT:  Oops, I see you did mention your mics.  They are omni so it won't really make any difference where you point them, they will pick up everything around them.  Better if they were both cardioid for experimentation. You could certainly try playing around with some baffles and sound reflectors though.  You will learn a lot even if you end up upgrading... 🤓

[milan87]

Thanks for feedback.

Yes, both microphones are the same type, and omni-directional.

I expected pretty similar signal from both microphones, but from some reason this is not the case.

Even wire lengths are same, and shielded of course.

I also tried some baffles on mic2 (weaker signal) so can capture some more sound, and obstacle to reduce signal in mic1, but even with that, mic1 capture stronger signal then mic2.

Not sure if DAQ could make some stupid calculations?

So my next target is to get this two signals almost the same, so i will know that i have same capturing of the sound.

Sound source (hand clapping) is at greater distance then distance between microphone.

Any further discussion, and suggestions are more then a welcome 🙂

Thanks a lot.

[milan87]

I manage to find what was the issue about different signals from 2 mics.

One of resistor in mic circuit has different value. And now the diagrams are pretty the same.

I think it could not be better with this hardware.

But now i noticed, that click sound isn't the same every time. I made a couple of pictures in pdf in att.

Currently i check if there is a pick at one frequency, more specific 12kHz +/-10% in this case.

Amplitude level is sometimes weaker and sometimes is stronger at that frequency.

But hand clapping also provide that frequency with higher amplitude, so system cannot distinguish is it hand clap or click.

Additional, I cannot limit the amplitude high limit, because sometimes clapping and click have same amplitude.

So i need better way to filter click sounds.

[milan87]

Hello again,

i  really appreciate if someone can explain why is this happening.

I'm doing acquisition with VI in attachment.

If i try several time to capture the click sound, waveform in time domain looks the same in most cases, but after FFT, spectral diagram in frequency domain looks different.

FFT OK                                                              small amplitude FFT                            FFT not clean

Not sure why is this happening.

Also tried to remove part of waveform before trigger, and seems that there is no improvement in FFT diagram.

Unfortunately, Mielhaus 1208 doesn't have option to use trigger function of ULx, so cannot trigger internally.

So i need to use basic level trigger detection on waveform.

Any idea how to overcome this spectral diagram issue?

Thanks.

[Kevin_Price]

It would be much more useful if you showed the respective graphs for the *subset* of data you retain after the software trigger detection.  That is, "Waveform ROW 3" and "Spectar ROW".   Also be sure you "save as default" the front panel values you use for level and hysteresis.  What showed up in the vi you posted is 0's for both, which would certainly not be effective settings for detecting the start of a "click".

-Kevin P

[wiebe@CARYA]

I'd be worried about timing too. At least enough to do the math and tests.

There's cables, input buffering, AD conversion, processing, DA conversion, more output buffering, more cables...

You might easily have a latency of 100-500 ns, which might be significant if you're trying to cancel noise.

NC Earphones are tightly packed, and I'm sure there's a good reason for it.

[NIquist]

You're probably going to need to completely clip your "clap" out of the signal to get a good FFT.  You might also try windowing the signal to get more consistent results.

Check this out:  Understanding FFTs and Windowing.pdf (ni.com)

Hint, if you want more people looking at your code, back-save to 2018 or so with the Save for Previous... option.  😉  (Many of us locked in at our current version to avoid the forced software subscription.)

You can also put your data in graphs and controls and it will save with your VI if you do: Edit > Make Current Values Default before you save.

[wiebe@CARYA]

---

@NIquist wrote:

 clip your "clap"

---

The VI should be named Clip Your Clap Filter.vi 😁.

[milan87]

Yes, you have right, i forgot to save default values.

Trigger level is 4.5, and hysteresys is 2.

Tomorrow i will provide data in array.

[BertMcMahan]

---

@BertMcMahan wrote:

Instead of filtering the noise, filter the click detection.

If Mic 1 detects a click AND Mic 2 detects a click, ignore it. If Mic 1 detects a click and Mic 2 does NOT, then it's a valid click.

---

I'd like to bring this up again- as I understand it, you can reliably detect clicks and background clicks from the "close" mic, and you can detect clicks from the "far" mic. Why do you need to cancel ALL of the noise? If all you care about is clicks, then just detect all the clicks you want and decide whether or not to act based on which mic(s) detected it.

That will be WAY simpler than trying to do active noise cancellation. The thing to remember is that you're only trying to detect ONE sound- not cancel all arbitrary noise from everywhere. Reverse what you're trying to do- instead of filtering noise, filter the clicks.