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

Re:Not in planes...

[Anonymous Coward]

Did you know that, when pilots report problems, in 50% of the cases, maintenance can't find the cause of the problem? This means that one half of the airplanes that have potentially harmful problems keep flying unrepaired.

No it doesn't. It means that 50% of the time problems are reported by pilots, maintence can't find the problem.

Your factoid says nothing about: The harmfulness of the reported problems, the rate at which the problems are reported by pilots, and if pilots ever score false poisitves reporting problems. All of these factors would be needed to arrive at your "half of the airplanes ..." conclusion, and these are factors you have not established.

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.

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 [wikipedia.org] 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 [wikipedia.org]
http://en.wikipedia.org/wiki/Real-time_computing [wikipedia.org]
http://en.wikipedia.org/wiki/Real-time_operating_s ystem [wikipedia.org]
http://en.wikipedia.org/wiki/Audio_signal_processi ng [wikipedia.org]
http://en.wikipedia.org/wiki/Noise_cancellation [wikipedia.org]
http://slashdot.org/article.pl?sid=04/05/27/164125 4 [slashdot.org]

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.