Noise Cancelling in Software?

doc_verma wonders: "There are directions to build noise-cancelling devices in hardware, but what would it take to create noise cancelling in software? Since computers have a speaker-of-sorts and can possibly have a microphone, why not take the input from the mic, reverse-phase it via software, and output it through the speaker? A noise-cancelling feature would be great to run on servers in a rack. It would also be a great app to run on your laptop when you are on a plane."

Comments

Uh, no.

[QuantumET]

You'd only get noise cancellation at the rough area around the microphone is, assuming you'd account for the speaker-microphone distance. You have to cancel phase _everywhere_ for it to work for a room, and you can't do that, really, without a huge array of speakers, or speakers exactly co-located with noise sources.

So you could do it in software for headphones, since you just need to cancel noise right at the headphones, which is fine. But it's no good for speakers, unless you have very specific configurations of noise sources that lend themselves to simple cancellation. In general, no way.

Re:Uh, no.

[khanyisa]

Actually the place to do the noise cancellation is at the source of the sound - i.e. the fan - see http://slashdot.org/article.pl?sid=04/03/15/232222 2

Re:Uh, no.

[Anonymous Coward]

I am an electrical engineer.

Parent is exactly right. There are two ways to handle noise cancellation. #1 is source cancellation (very hard unless the source is confined). #2 is receiver cancellation (very easy). However, don't expect either method to work at high frequencies.

Sound is a complex beast. Literally. Imagine you could have enough samples to make a 3D spectrum analysis of the sound. What would it look like? You'd see high frequencies "beaming" off of reflective surfaces. You'd see low frequencies "wrapping around" small objects.

To do source cancellation, you have to find a way to negate all of the sound energy before it reaches *any* receiver. Put your computer in a box with a long, narrow air take. Carefully design the intake/exhaust to minimize "port noise". Add noise cancellation *inside* the box. Walk around. You shouldn't hear anything coming out of the box.

If you can't control the source, you have to resort to receiver cancellation. "Why?," you ask. Because if you mess up on the phase, you can/will end up contributing 3dB to the noise source at various frequencies/locations. That's not acceptable.

Receiver cancellation works just like source cancellation, except you put the box around the receiver. In our case, the "box" is headphones. Put a high quality microphone on one side. Feed a phase-inverted signal into the output speakers.

Earlier I mentioned that noise cancellation doesn't work well at high frequencies. Why is that? Delay. At low frequency, the signal changes very slowly. If I'm "off" by 1 microsecond, it won't make any difference to a signal that oscillates at 60Hz. Here's a little exercise for the reader:

F(t) = cos (2 * pi * f * t) - cos (2 * pi * f * (t + d))

In this example, we're considering only one frequency and one point in space. Let f = 60Hz. Let d vary from 0 to 16ms. Observe the results. What happened at 2.79 ms? At 8.33 ms? Nasty, eh? But we're pretty confident our system can handle those latencies without any trouble, so we'll crank this thought experiment up to 4kHz.

Let's do some envelope calculations: our latency has to be under 42 microseconds to do *any* good (i.e. avoid adding to the noise), under 21 microseconds to get a 3dB attenuation, under 4.2 microseconds to get -10dB, and under 0.4 microseconds to get -20dB. No sweat, right? :-)

I'm going to be a bit facetious here and start by examing the CPU aspects. Ok you've got a 3GHz cpu. Let's be "generous" and assume you get about 1.67 instructions/clock. That means you can execute about 5e9 instructions/second (0.2 microseconds/instruction). There's no way you could hope to get any meaningful work done in 2 instructions, so that rules out the possibility of getting -20dB. In fact, there's not much you could hope to do in ~20 instructions, so there goes -10dB. You *might* be able to write a dedicated driver that could handle -3dB. Whooptee freaking doo *twirls finger*. The padding on your headphones probably does a better job. Or just stick some cotton in your ears.

Even if you manage to get your digital hardware up to speed, you've got another problem: the analog hardware. That's right: between your $0.50 microphone and your $0.50 speaker, there's a pretty decent chance that they've got more than a few microseconds of slew error. Even if you bumped those up to $100.00 each, you're still not likely to get it right. In short: don't expect to do -20dB at 4kHz for under a few grand (*).

Last I heard, the $100 sony headphones do about -10dB at 100-400Hz. As far as I can tell, the hardware is only worth about $2, and you're paying $98 in salesman, middleman, marketing and engineer salaries.

(* No, this is not an offer. I wouldn't try building you a pair for less than a million in R&D funds, and even then I couldn't guarantee results.)

Position dependence

[addaon]

Do you sit in the exact same relative position to the speakers (within a quarter of a wavelength or so) at all times? If not, that idea's dead.

Re:Position dependence

[Ratso Baggins]

and further and perhaps more importantly there's time delay. In order for the wave to be present at your ear at the exact same time as the anti-phase wave, the ant-phase must be calculated and delivered in real time. The only real way to do this today is with an analog amplifier because dealing with the signal digitally introduces delay (eg: A/D) which cannot be compensated for (in that, the event is over before the anti-phase signal is produced.

Real-time sound

[mbrubeck]

Your computer's sound input and output are buffered in both software and hardware. This means that there will be a minimum latency measured in tens or hundreds of milliseconds between reading input from the microphone and being able to send corresponding output to the speakers. You can make this latency smaller and more predictable with well-designed hardware, drivers, and applications software, but you'll never be able to do the same "real-time" processing that you can do with dedicated hardware.

Re:Real-time sound

[ivan256]

That doesn't matter. You only cancel constant background noise, so you're canceling based on feedback from sound heard earlier. That's how the headphones work too. (You don't think they have instantanious electronics do you? Even anlog signals have latency.) The real problem comes with phase alignment, which will only be possible at certain points, not everywhere. If you use headphones you could probably do noise cancelation in software without a problem. It would just be fussy, and you'd have to tweak the settings all the time to keep the phase right.

Re:Real-time sound

[munpfazy]

>That doesn't matter. You only cancel
>constant background noise,
> so you're canceling based on feedback
>from sound heard earlier.
> That's how the headphones work too.

But there's a big difference between trying to match the phase of a signal using analog parts with an intrinsic bandwidth of MHz and trying to match the phase of a signal when you're latency is several ms at best and varies wildly depending on what the computer is doing.

If the latency were constant to within a small fraction of the period of the highest frequency you need to cancel, then you could do it. But you'll be hard pressed to get there using a multi-tasking OS on a standard laptop.

To make a super-conservative estimate: let's say you want to compensate for only 100 Hz noise and you demand only that you get the phase right to within 45 degrees. That means you need latency changes to be constant to less than 1.2 ms. That's mighty ambitious for anything but a dedicated real-time system.

One might imagine that if the noise environment changes slowly and you have a great deal of control over everything the computer is doing you might be able to pull it off. But it sure sounds like a lot more work than building it out of dedicated hardware. And the potential for screw-ups - like occasionally getting the phase wrong by more than 90 degrees and generating a positive feedback burst that deafens the user - is pretty scary. You'd have to put some thought into making the system safe.

Re:Real-time sound

[Aaron Denney]

> You only cancel constant background noise, so you're
> canceling based on feedback from sound heard earlier. That's how the headphones
> work too.

Actually, it isn't. You can cancel one-tone that way unless you constantly do a
windowed FFT.

> (You don't think they have instantanious electronics do you? Even anlog signals > have latency.)

Not instananeous, but orders of magnitude faster than digital. Most do in fact just invert the signal. Headphones make the sound directional enough so that it can work.

> The real problem comes with phase alignment, which will only be possible at
> certain points, not everywhere.

Correct. With enough speakers and microphones it might be possible over fairly broad areas, but the variable latencies kill you.

Re:Real-time sound

[ivan256]

Judicious use of the hardware buffering and some fiddling by the user should be able to overcome the latency deficiency. You just need to write more than your average latency worth of audio to your buffer at a time, and the padding you place at the beginning of your first sample will give you as fine grained control of the phase as you need.

But you'll be hard pressed to get there using a multi-tasking OS on a standard laptop.

It depends on the OS. Some allow you to change kernel code. That lets you do your timing sensitive operations with interrupts disabled. With the right hooks in your DSP driver you may not reduce the latency, but you could practically eliminate the latency jitter (the real problem) during your calculations.

Too slow

[QuietRiot]

Software would generally be too slow. A DSP-based sound card could potentially be programmed to do phase-inversion and time-slew (to account for distance) but an ordinary desktop machine would generally need to be very fast and incorporate real time extensions in the kernel. This is the reason you generally find hardware-only solutions (and in headphones for the reasons mentioned in a peer post). Of course I could be way off....

Re:Too slow

[Grab]

I'm afraid you need more hardware experience... :-/

That's certainly fast enough to do "output = -input;". Your problem though is converting analogue voltage to "input", reading "input", writing "output" and converting "output" to analogue voltage.

The *best* soundcards currently available are 96kHz. Nyquist says that you can only reproduce a frequency of 0.5 x sample rate. But that's theoretical-only - to get a decent approximation takes you to more like 0.1 x sample rate. Which means you can accurately reproduce sounds up to 9.6kHz. Probably OK for fixed noises like motors, but not much good for white noise.

But even then, you've got another problem of time delay. The best real-time digital sound processor takes 1 sample time to read data and 1 sample time to process it. (There's also write time, but you can combine that with processing time, if we're assuming the theoretically-best system.) So you've got 2 samples delay, which is 0.02ms. That's acceptable. PCs though typically have a time delay of around 2ms in reading data (and that's on a *good* system). This means that any sound you output will be 2ms behind. Combining them gives a resultant noise at 500Hz. You can use prediction to reduce that, but the limit of the time delay means you'll never be able to noise-cancel at more than 500Hz.

In other words, using a PC for noise-cancelling is useless, and the OP is a fucking dipshit.

In retaliation, I'm tempted to post an "Ask Slashdot" for "Why can't we build space elevators today? After all, we only need a long rope, and the US wire-making industry churns out miles of steel cable every year. That should be fine, shouldn't it?" ;-)

Grab.

Re:quiet fans aren't too expensive

[karnal]

The problem with quiet fans in a server-room / rack style environment is that the quiet fans typically don't move a lot of air.

I've got a 2u switch, with some 60mm fans in a small 6 foot rack in my basement. The fans aren't too loud in and of themselves, but they make a hell of a lot of wind noise and turbulence - because they run at 5000rpm. Now, since I can control the air temperature a little better in my situation than you might in a server room (by not having a crapload of equipment in the rack), I could probably replace them with 2500rpm fans.

But I digress. The people who make this equipment have to have high airflow - they can't have their equipment fail on you, the consumer, even if you abuse the room they're in (temperature wise...)

I've also played with 1u servers, with insanely fast, whiney whooshing fans. They are REQUIRED, if you ever feel the heat they move off the back - you'd know why.

In short, in a server room, there's not much you can do about the noise. Just insulate the room and keep the noise on the inside.

why not...

[croddy]

why not take the input from the mic, reverse-phase it via software, and output it through the speaker? well, i suppose the howling, squealing feedback would make you forget about the server fans for a few seconds, but i suspect it would just end up giving you a bigger headache in the long run.

My child once talked for eight hours straight ...

[joelsanda]

... on a road trip across the West. Eight solid hours of a four year old pontificating. I searched the car high and low for the travel headphones so I could get a break with my MP3 player. Couldn't find them and the only stores for thousands of miles in any direction sold only alcohol, Mormon cookbooks, and knives.

This is a cool idea.

Loud Noise

[DavidLeeRoth]

I dont know how to noise cancel, but I know how to create a ton! cat /dev/urandom > /dev/dsp :)

Fenton Silencer

[the eric conspiracy]

You want one of these

This is possible with two specific caveats.

[stvangel]

The biggest issue is to only have one specific sound source you're trying to muffle. You have to place the microphone as near to the sound source as possible, and the location of your speaker will depend on how long it takes to process the signal. It will also be highly directional unless you rig something up with multiple speakers all aimed in different directions. You will also need to be a certain distance away to allow the reverse-phase sounds to merge and cancel each other out.

The other issue is that it will only work on low pitched sounds, the lower the better. The slower the frequency, the more time you have to do the math and output your opposite signal. High frequency sounds you can pretty much forget about being able to process.

One use for this might be to muffle a single exhaust pipe from a loud motor, but you won't be able to get it to work for general noise. The reason it works in Noise-cancelling headsets is that the microphone is located at the destination of the sound (your ear), rather than at the source. The closer you can get it either end, the better it will work. It's not really worth doing it in Software

One interesting thought about quieting individual fans or motors is to use an Adaptive algorithm. Because most of these devices make a consistent repeating sound, it would be interesting to be able to anticipate the sound source over time and broadcast an estimated calculation before the current sound is even processed and use the processed result to tweak the future estimation. This would work on only reasonably consistent sources and there would be issues with feedback and unexpected noise changes.

Re:My child once talked for eight hours straight .

[joelsanda]

Your poor child. I hope you have money saved for the therapist.

Yeah, for me. He got that from his mother.

Re:My child once talked for eight hours straight .

[OneDeeTenTee]

the only stores for thousands of miles in any direction sold only alcohol, Mormon cookbooks, and knives.

Sounds like a bad day for the Mormons if you're hungry.

Why did this get approved?

[Refrozen]

This isn't Slashdot worthy material, but I'll answer it with some information anyways.

The key to noise cancelling is direction. The inversed noise has to be travelling in the same direction the noise otherwise would, and it has to be inverted and spat out at almost the exact same time.

While the speed issue isn't a problem, the microphone and speakers aren't good for the directionalness. It works well in headphones, because with headphones you have a very specific direction: in to your ear. The microphone can pick up things relatively directional (depending on the type of mic.) but the speakers are made to spread sound, not to aim it.

That and they would have to be in roughly the same location (within a few cm.) for it to work properly.

What I want, is a noise cancelling dome, so two people can go under it, talk, and have no one outside hear anything, that'd be cool.

Re:Why did this get approved?

[AthenianGadfly]

What I want, is a noise cancelling dome, so two people can go under it, talk, and have no one outside hear anything, that'd be cool.

You know, something like that should be possible to create, using a special new noise-cancelling material. I think they call it "concrete".

So you think you're fast.......

[QuietRiot]

I'm sure that would be fine. It's your audio capture device, the pipelines on the card, DMA transfers, bus speed/contention, and system schedulers that are the problem. Oh yeah. All *that* stuff.... And then you need to get back through the bus, card pipelines and out through the DAC to generate output. Phew!

Dedicated, you'd probably be fine at 100Mhz or less with the right [embedded : most likely hand coded assembly] software. Most modern desktops have so much crap running all the time however that those precious CPU cycles dissapear very quickly. Even if you could do it, there'd probably be gaps or delays without some nicely written double or triple buffering techniques. These things take time and then therefore kill what you set out to do.....

Actually - If the microphone was placed very close to the source, you may be able to generate some anti-sound "down range" (ie. Your desk) and the latency could be compensated for in that regard. It would take some fine tuning - in fact another microphone at the place where you need the quiet could be used for the system to tune itself. (This of course is assuming there are no walls in the room for the sound to bounce off of so that you aren't trying to defeat 17 "sources" simultaneously).

I'm not claiming any authority on this or saying it can't be done, just stating that it's probably quite a bit more complicated than it may look at first glance. Real time work is not something most "normal" OSes are setup to do. It can be done, but for things to be faster than sound you've got to get your latency WAY WAY WAY down.

http://en.wikipedia.org/wiki/Real_time
http://en.wikipedia.org/wiki/Real-time_computing
http://en.wikipedia.org/wiki/Real-time_operating_s ystem
http://en.wikipedia.org/wiki/Audio_signal_processi ng
http://en.wikipedia.org/wiki/Noise_cancellation
http://slashdot.org/article.pl?sid=04/05/27/164125 4