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: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 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: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.