It wasn't but a few months ago (3/25/2002 as reported by this story) that Bell Labs/Lucent demonstrated 2.56 Tb/s over 4000km, compared to this story's 401 Mb/s over 12300km -- about six thousand times as much bandwidth. While 401 Mb/s is pretty fast, its really not that great as far as these things go.
Okay, I admit it. I didn't understand a word of the article
Here's a few quick explanations of some of the key points mentioned in the article.
The leakage problem: This is a really difficult and nasty problem. It arises from the fact that designing a chip involves trading off a number of things, among which are clock frequency, operating voltage and power dissipation. It turns out that as you increase voltage, it speeds things up but it also causes power dissipation to rise as well. Ask any overclocker. However, the speedup is roughly proportional to voltage, while the power dissipation goes as the square of voltage. Hence the operating voltage of chips has steadily been decreasing. The bleeding-edge research type chips are down somewhere in the 1V - 2V range. The problem here is that there is a fundamental property of the FET called the threshold voltage, the voltage at which (more or less) the transistor switches from being ON to OFF or vice versa. Of course it's not a sudden transition, so its desirable to have the system voltage higher (say by 2X to 5X) the threshold voltage, so that the transistors are turned ON and OFF fully. Otherwise, leakage occurs, and can become a very significant power drain if not kept in check. The problem is that due to physics and some other factors, the threshold voltage cannot be reduced easily past a certain point. There are tricks that the designer can use to attack this, but it's still a very fundamental issue. So what the circuit designers end up doing to meet the design criteria is play a large game of cost-benefit analysis with regards to power, frequency, system voltage, threshold voltage, area (die size), etc.
Masks: Integrated circuits are build up in layers. An extremely simple design might have 6 layers, modern CPUs might have 20 or more layers. Each layer is created with a mask that defines the features of the layer. While enlargement/reduction is used (meaning the mask features are larger than the features on the wafer), mask creation is still very difficult. It's like making a stencil with millions of tiny features. The photolithography involves very expensive machines with extremely precise optics. Indeed you might have heard of the push to "extreme ultraviolet" - this refers to the light source which shines through the mask and exposes features on the silicon wafer. The trend is to use smaller and smaller wavelengths, because the feature size keeps shrinking. The wavelength of light that is used must be significantly smaller than the smallest feature, otherwise you get interference/fringing/etc. Anyway, these masks are very expensive to produce, leading to very little room for error. You want to be sure that those masks are at least functional, and hopefully as bugfree as possible. To a certain extent you can work around some hardware bugs, but it's very stressful because of the huge cost and time delay (many months) of getting a design fabricated. Imagine what development would be like if compiling your source code one time cost you a million dollars and took 6 months. Now try to stay competitive in a market where everybody is screaming at you to get a product to market as quickly as is humanly possible. Simulation is the name of the game here.
Interconnects: This refers to connecting together the individual transistors to form blocks, connecting the blocks to form modules, etc, up higher and higher levels. Interconnects do not scale well, it's just one of those complexity things. The number of interconnects goes something like N^2 (where N is the number of transistors), and this can quickly get out of hand. The problem is you can't just make the wires longer (by wires I mean the etched paths inside the chip, not the external things) because this increases their resistance and capacitance, which means that they must be driven "harder" to achieve a given performance. To drive them harder you must spend extra area on larger transistors (which just complicates things -- now the chip is even more spread out) or spend more power, which is usually not feasible. A stopgap measure is to use copper instead of the traditional aluminum for the interconnects, but this is only really a one-shot thing, it only buys you so much. Another way is to use more interconnect layers (expand in the "z" direction) but this has its problems as well. The most promising solution to the interconnect issue is with advanced CAD algorithms and plain old good design. Keep related modules close to each other, and design busses to shuttle things around longer distances.
Capacitance: Capacitance is one of the worst enemies of the circuit designer. It means that on every transition of state, energy must be spent charging (or discharging) a dielectric. This is one of the main reasons for reducing smaller feature size -- smaller things have less capacitance. The article mentions fully depleted SOI, which is basically a very extreme way of trying to reduce capacitance. The bulk substrate is silicon dioxide, an insulator, instead of pure crystalline silicone (a conductor.) The effect is to decouple the individual transistors from the bulk substrate of the wafer. The result is much less stray capacitance, but the cost is that your transistors no longer work quite right so it makes circuit design that much more complicated. The article also mentions high-k dielectrics, which basically is a way of increasing the "gain" or drive strength of a transistor without increasing its size, which is the normal way of doing things. It can be really quite frustrating: if a path in your circuit is too slow, you have to increase its drive strength. But this also increases the capacitance (which leads to more power dissipation) and now the thing that drives that circuit also has to be bigger (to compensate for the increased gate area), etc, etc. Any means of increasing the drive strength without increasing area is quite beneficial.
Well, first let's assume that this is not another of those "Dear Slashdot: Will You Please Do My Homework For Me?" submissions. I realize you were trying to be brief and concise, but in order to proceed with this design you will have to nail down some details first.
For instance, how many strings? I would assume it's more than one octave and less than five or so. Also, how many polyphonics do you want to support? That is, how many strings can be "played" (i.e. beam interrupted) at once? You can make the hardware really simple if you only support one string at once. But it wouldn't be very useful. A design in which you support full polyphony, where any possible combination can be played, will be more complex but it will also be more realistic. The whole idea here is that you can vastly reduce the number of i/o lines required if you do some encoding or grouping of the strings, at the price of not allowing certain combinations of strings to be simultaneously addressed. If you want this instrument to be practical, you must think hard about the multiplexing (if you go this route.)
Another thing to decide early on is whether you want to deal with velocity data. A decent midi keyboard will sense how hard you press the keys, and include this data in the midi stream. It would be really neat to detect how fast your photodetectors are covered by the fingers (to simulate plucking the string violently vs. gently strumming it), but this would add greatly to complexity, so I suggest avoiding it.
Don't be afraid to use multiple PICs. If I were doing this design I would consider a two-tier design. Perhaps a three dollar 16F627 for each octave, with one i/o line per string (this gets around the multiplex issue.) Unfortunately I don't think you will be able to use interrupt-on-change for every string, so these first tier chips would periodically scan their 12 strings for an event. You can do the debouncing in software, but it's probably easier to buffer the photodetectors with Schmitt triggers. Each of the first tier chips would talk to a central second tier chip which aggregates the events and encodes them as a midi stream. Those 16f627's have up to 15 i/o lines, so that leaves 3 for communication with the master. You could use something standard like I2C, or just invent your own protocol. You might be able to do something as simple as one data line and one handshake line (if you have a common clock for the whole unit) from each slave to the master. The idea here is that rather than a single chip constantly trying to keep track of the state of a number of strings, the master simply receives a few bits of data from one of the slaves whenever there's an event.
Anyway, those are my initial thoughts. The first thing you design should be the general architecture stuff, don't get bogged down in details. Have a general block-diagram sketch of the whole thing before you start building anything. Keep a notebook, and record all your design ideas, sketches, schematics, specs, etc. in one place. It will make your life much easier.
Like most of these it was light on hardware details, but this was hidden in one of the captions:
The spacecraft has a design mass of 416 kilograms (917 pounds) and is about the size of a small lifeboat.
On the journey to Pluto, the probe will reach a top speed of about 70,000 kilometers per hour.
The craft's computers will be able to store 48 gigabits of data and transmit the information to Earth at up to 770 bits per second from Pluto (16,000 bits per second from Jupiter).
48 gigabits of radiation-hardened memory must cost a fortune...I seem to remember that Flash ram is not suited to this kind of thing since its especially susceptible to energetic particles (alpha, gamma rays) dislogding the charge trapped in the gate dielectric (which holds the information.) Anyone know how data storage is usually carried out on these things? I can't imagine using anything with moving parts, and since the craft is supposed to be powered down for most of the time while it drifts, I'd think you'd want something non-volatile. I would hate to think what would happen if there was a brief power shortage or something and all the readings from the entire mission that were queued up to be sent were lost.
As to the 770 bits/s, I'm amazed it's even that fast. Consider that the RF power decreases as 1/r^2, where r is about 7.5 billion km. They are using a directional 2.5m antenna, lets say that's 100 dBi gain. Still, even if they managed to transmit 10W at the satellite (which is a lot for radio), we'd receive about a picowatt (1e-12) of it here on earth. I've heard that number thrown around before as a typical power level that we receive from deep space, and it boggles the mind that we can detech such faint signals... guess that's why it takes arrays of gigantic dishes with supercooled LNAs to do it. And it's great example of how power and bandwidth are related in communications. The more power your signal has at the receiver, the more information you can convey (bandwidth.)
I would like a feature that the links in the posted stories open in new windows when I click on them. This would probably have to be a per-user preference that defaulted to OFF, but I'm probably not alone in wanting this. I usually shift-click to do this but it would be a tad more convenient if this was automatic. It would be double-nice if links posted in comments would be configurable this way as well.
Another small idea would be the facility for a link to a mirror of a slashdotted resource to automagically appear in the news posting if some kind karma-whore posts it in the comments. It happens often: site is slashdotted, and someone has posted a link to a mirror. Usually the post is moderated up quickly, and all I'm suggesting is some way for this information to propagate to the story posting, such as "[mirror here]" added to the text of the post. Obviously, this would have to be tightly controlled so that the goatse folks don't go crazy with it, so maybe it would have to be under the editors' or story-authors' control.
I would be happy to pony up a few bucks if these or some other minor features were added.
An example of research in user interfaces is Denim which aims to marry the advantages of old fashioned pen+paper design with the convenience of having the computer handle the details. The idea is to allow the designer to freely sketch with a tablet but also add hyperlinks between sketches as the design progresses. There's a sample of the generated mockup, but really the videos on the page linked above are really neat. They show a person using a tablet to do a sample design. The software also incorporates some other modern interface ideas such as the zoomable UI and the pie menu.
The kimchi, as you might guess, glowed a pleasant yellow as it gave off a rather unpleasant vapor. (The Dustbuster and carbon filter system was not sufficient to keep up with the smell.) Then Dan Jackson noticed the oscilloscope trace. The lower trace showed the voltage across the kimchi. It was running at about 140 V RMS. Then he saw the upper trace. The upper trace showed current pulses of about 4 amperes in amplitude. Dan called out "Hey! The kimchi is acting as a rectifier!"
Here are some more links to discover if you are behind a transparent proxy. Presumably these will get around any IP spoofing that the proxy might do since they're intended for this and not just "What's my IP?" although I really don't know the details of how these work.
To get a signal shifted by a uniform 90 degress across all frequencies, I believe you want to use the Hilbert Transform.
As far as applications, if you're using windows, there are a number of very advanced audio editor programs, like Cool Edit, Goldwave, etc. Try a search at one of the usual software download places.
Probably the most extensive DSP applications turn to something like Matlab, but that's hardly free.
For a unix-style solution, there's a package of tools here called pipewave which allows you to do very complicated digital signal processing using unix pipes. It follows the philosophy that you can do very complicated tasks by cascading smaller components using pipelines. Here are some examples from the above site:
Plot the Fourier transform of a file using a Hanning window.
fd file | fft -h | plot
Generate the default synthestic vowel (200 ms duration, fundamental frequency = 100 Hz and formants, F1 = 650 Hz and F2 = 950 Hz), halve the sampling rate, take the hanning-windowed Fourier transform, and plot
klatt -k | downsample 2 | fft -h | plot
Generate 2000 samples of white noise, pass it through a gamma-tone filterbank (1 channel per ERB), arrange the filtered waveforms in a cascade, such that there is no overlap between them and plot.
Generate 2000 samples of white noise, store a copy of the original in a file called 'noise0', then phase shift it by 90 and store the phase shifted version as 'noise90'.
gaussian 2000 | store -o noise0 | fft -p | ffilt -a 90 | ift | store noise90
Do not steal the focus, neither on startup nor for any sort of dialog box.
Respect my preferences. I do not have the default gray color scheme, so do not hardcode gray as your icon/toolbar/dialog background color, etc. Also recognise that I might have the taskbar docked on the lefthand side. I run across programs all the time that think that if they pop up a window at (1,1) it will be visible since the task bar is at the bottom of the screen.
Do not go against the sound effects or window animations that I have configured. I have some sound effects enabled, some disabled. Some people have no speakers or are at work and have sounds disabled. Same thing for window animation. I have most of it disabled, so don't assume that I enjoy those stupid animated "unrolling" menus.
Remember the window position/size and always open to the last state. I hate apps that are too dumb and must be resized/moved each time they are started. Usually this is related to the prior point about not having the standard windoze explorer configuration.
Do not use any pauses. Don't pop up an error window for 3 seconds (with no ability to make it go away) or some such nonsense.
Avoide the splash screen at startup. DO include a useful version number in the About dialog, with contact info and a website for updates. Avoid auto-detecting updates unless you are clear and upfront with the user before going out to the network.
Any time you report a filename in a panel or status display, please test your app with long filenames or filenames with multiple spaces. Often when processing files that reside in the "My Documents" folder, programs will try to report the filename but only output "C:\Documents and" when the file was really named "C:\Documents and Settings\Administrator.BOOCH\My Documents\Recorded Shows\file.avi". A related point, if you must abbreviate filenames to fit in a limited space, consider only showing the trailing bits (i.e. the actual filename and as much path as can fit) rather than the other way around, showing the higher level directories first and cutting off the subdirectories and filename.
Don't include the runtime if at all possible. I always respect a 500k install package over a 4MB one. Don't put any "common files" in my system32 directory if you can avoid it.
Use an intelligent installer. I want the program's directory completely removed when I uninstall, not left empty or with some small derelict file that the installer didn't know about. Same deal with the registry. Don't leave an empty key when your program uninstalls. I will disagree with other posters here, there's absolutely nothing wrong with using the registry intelligently.
I should not have to reboot to use your application, unless there are very special circumstances. Win2k is pretty good about this, actually. And for all that is holy, DO NOT make an installer that forces a reboot as the last step.
Tell the user what's going to be changed during installation, and give him or her a choice. The default for icons should be a directory under Programs in the start menu. DO NOT install an icon on my desktop or in my quick-launch bar without asking. DO NOT put your app directly on the start menu "root" menu.
Default install location should be Program Files, not a random directory off the root (like C:\MyApp) but in any case it should be presented as an option during install.
Do not add anything to my startup without asking. If I like your program and want it to run automatically at boot then I will either use a checkbox in your config screen or I will put a shortcut in the startup folder.
Don't litter my temp directory. Delete whatever temporary stuff you create.
You didn't mention anything about your hardware, but I had the exact same thing happen to me with the Highpoint 370 controller on a KT7-RAID motherboard. I rebooted one day to find that the HPT BIOS would say only "broken stripe." I figured my NTFS partition was toast. But there is a utility, raidrb, which I think is written by either Via or Highpoint. Anyway you just boot from a floppy and run it and it "reassures" the controller that the stripe is really ok.
There is some discussion of other methods to try if this one does not work in the Raid section on Paul's KT7 page. (Google search for "kt7 faq" for the url.)
See also DCC, the distributed checksum clearinghouse. It uses a fuzzy hash so that bulk emails with minor differences are caught. I think the details differ a lot but the idea is more or less the same.
Slashdot Mirror
It wasn't but a few months ago (3/25/2002 as reported by this story) that Bell Labs/Lucent demonstrated 2.56 Tb/s over 4000km, compared to this story's 401 Mb/s over 12300km -- about six thousand times as much bandwidth. While 401 Mb/s is pretty fast, its really not that great as far as these things go.
Here's a few quick explanations of some of the key points mentioned in the article.
The leakage problem: This is a really difficult and nasty problem. It arises from the fact that designing a chip involves trading off a number of things, among which are clock frequency, operating voltage and power dissipation. It turns out that as you increase voltage, it speeds things up but it also causes power dissipation to rise as well. Ask any overclocker. However, the speedup is roughly proportional to voltage, while the power dissipation goes as the square of voltage. Hence the operating voltage of chips has steadily been decreasing. The bleeding-edge research type chips are down somewhere in the 1V - 2V range. The problem here is that there is a fundamental property of the FET called the threshold voltage, the voltage at which (more or less) the transistor switches from being ON to OFF or vice versa. Of course it's not a sudden transition, so its desirable to have the system voltage higher (say by 2X to 5X) the threshold voltage, so that the transistors are turned ON and OFF fully. Otherwise, leakage occurs, and can become a very significant power drain if not kept in check. The problem is that due to physics and some other factors, the threshold voltage cannot be reduced easily past a certain point. There are tricks that the designer can use to attack this, but it's still a very fundamental issue. So what the circuit designers end up doing to meet the design criteria is play a large game of cost-benefit analysis with regards to power, frequency, system voltage, threshold voltage, area (die size), etc.
Masks: Integrated circuits are build up in layers. An extremely simple design might have 6 layers, modern CPUs might have 20 or more layers. Each layer is created with a mask that defines the features of the layer. While enlargement/reduction is used (meaning the mask features are larger than the features on the wafer), mask creation is still very difficult. It's like making a stencil with millions of tiny features. The photolithography involves very expensive machines with extremely precise optics. Indeed you might have heard of the push to "extreme ultraviolet" - this refers to the light source which shines through the mask and exposes features on the silicon wafer. The trend is to use smaller and smaller wavelengths, because the feature size keeps shrinking. The wavelength of light that is used must be significantly smaller than the smallest feature, otherwise you get interference/fringing/etc. Anyway, these masks are very expensive to produce, leading to very little room for error. You want to be sure that those masks are at least functional, and hopefully as bugfree as possible. To a certain extent you can work around some hardware bugs, but it's very stressful because of the huge cost and time delay (many months) of getting a design fabricated. Imagine what development would be like if compiling your source code one time cost you a million dollars and took 6 months. Now try to stay competitive in a market where everybody is screaming at you to get a product to market as quickly as is humanly possible. Simulation is the name of the game here.
Interconnects: This refers to connecting together the individual transistors to form blocks, connecting the blocks to form modules, etc, up higher and higher levels. Interconnects do not scale well, it's just one of those complexity things. The number of interconnects goes something like N^2 (where N is the number of transistors), and this can quickly get out of hand. The problem is you can't just make the wires longer (by wires I mean the etched paths inside the chip, not the external things) because this increases their resistance and capacitance, which means that they must be driven "harder" to achieve a given performance. To drive them harder you must spend extra area on larger transistors (which just complicates things -- now the chip is even more spread out) or spend more power, which is usually not feasible. A stopgap measure is to use copper instead of the traditional aluminum for the interconnects, but this is only really a one-shot thing, it only buys you so much. Another way is to use more interconnect layers (expand in the "z" direction) but this has its problems as well. The most promising solution to the interconnect issue is with advanced CAD algorithms and plain old good design. Keep related modules close to each other, and design busses to shuttle things around longer distances.
Capacitance: Capacitance is one of the worst enemies of the circuit designer. It means that on every transition of state, energy must be spent charging (or discharging) a dielectric. This is one of the main reasons for reducing smaller feature size -- smaller things have less capacitance. The article mentions fully depleted SOI, which is basically a very extreme way of trying to reduce capacitance. The bulk substrate is silicon dioxide, an insulator, instead of pure crystalline silicone (a conductor.) The effect is to decouple the individual transistors from the bulk substrate of the wafer. The result is much less stray capacitance, but the cost is that your transistors no longer work quite right so it makes circuit design that much more complicated. The article also mentions high-k dielectrics, which basically is a way of increasing the "gain" or drive strength of a transistor without increasing its size, which is the normal way of doing things. It can be really quite frustrating: if a path in your circuit is too slow, you have to increase its drive strength. But this also increases the capacitance (which leads to more power dissipation) and now the thing that drives that circuit also has to be bigger (to compensate for the increased gate area), etc, etc. Any means of increasing the drive strength without increasing area is quite beneficial.
I hope that was of some use to at least someone.
Well, first let's assume that this is not another of those "Dear Slashdot: Will You Please Do My Homework For Me?" submissions. I realize you were trying to be brief and concise, but in order to proceed with this design you will have to nail down some details first.
For instance, how many strings? I would assume it's more than one octave and less than five or so. Also, how many polyphonics do you want to support? That is, how many strings can be "played" (i.e. beam interrupted) at once? You can make the hardware really simple if you only support one string at once. But it wouldn't be very useful. A design in which you support full polyphony, where any possible combination can be played, will be more complex but it will also be more realistic. The whole idea here is that you can vastly reduce the number of i/o lines required if you do some encoding or grouping of the strings, at the price of not allowing certain combinations of strings to be simultaneously addressed. If you want this instrument to be practical, you must think hard about the multiplexing (if you go this route.)
Another thing to decide early on is whether you want to deal with velocity data. A decent midi keyboard will sense how hard you press the keys, and include this data in the midi stream. It would be really neat to detect how fast your photodetectors are covered by the fingers (to simulate plucking the string violently vs. gently strumming it), but this would add greatly to complexity, so I suggest avoiding it.
Don't be afraid to use multiple PICs. If I were doing this design I would consider a two-tier design. Perhaps a three dollar 16F627 for each octave, with one i/o line per string (this gets around the multiplex issue.) Unfortunately I don't think you will be able to use interrupt-on-change for every string, so these first tier chips would periodically scan their 12 strings for an event. You can do the debouncing in software, but it's probably easier to buffer the photodetectors with Schmitt triggers. Each of the first tier chips would talk to a central second tier chip which aggregates the events and encodes them as a midi stream. Those 16f627's have up to 15 i/o lines, so that leaves 3 for communication with the master. You could use something standard like I2C, or just invent your own protocol. You might be able to do something as simple as one data line and one handshake line (if you have a common clock for the whole unit) from each slave to the master. The idea here is that rather than a single chip constantly trying to keep track of the state of a number of strings, the master simply receives a few bits of data from one of the slaves whenever there's an event.
Anyway, those are my initial thoughts. The first thing you design should be the general architecture stuff, don't get bogged down in details. Have a general block-diagram sketch of the whole thing before you start building anything. Keep a notebook, and record all your design ideas, sketches, schematics, specs, etc. in one place. It will make your life much easier.
Brian
48 gigabits of radiation-hardened memory must cost a fortune...I seem to remember that Flash ram is not suited to this kind of thing since its especially susceptible to energetic particles (alpha, gamma rays) dislogding the charge trapped in the gate dielectric (which holds the information.) Anyone know how data storage is usually carried out on these things? I can't imagine using anything with moving parts, and since the craft is supposed to be powered down for most of the time while it drifts, I'd think you'd want something non-volatile. I would hate to think what would happen if there was a brief power shortage or something and all the readings from the entire mission that were queued up to be sent were lost.
As to the 770 bits/s, I'm amazed it's even that fast. Consider that the RF power decreases as 1/r^2, where r is about 7.5 billion km. They are using a directional 2.5m antenna, lets say that's 100 dBi gain. Still, even if they managed to transmit 10W at the satellite (which is a lot for radio), we'd receive about a picowatt (1e-12) of it here on earth. I've heard that number thrown around before as a typical power level that we receive from deep space, and it boggles the mind that we can detech such faint signals... guess that's why it takes arrays of gigantic dishes with supercooled LNAs to do it. And it's great example of how power and bandwidth are related in communications. The more power your signal has at the receiver, the more information you can convey (bandwidth.)
Nike to Cease Manufacturing Products
"From now on, we'll focus on just making ads," says CEO.
I would like a feature that the links in the posted stories open in new windows when I click on them. This would probably have to be a per-user preference that defaulted to OFF, but I'm probably not alone in wanting this. I usually shift-click to do this but it would be a tad more convenient if this was automatic. It would be double-nice if links posted in comments would be configurable this way as well.
Another small idea would be the facility for a link to a mirror of a slashdotted resource to automagically appear in the news posting if some kind karma-whore posts it in the comments. It happens often: site is slashdotted, and someone has posted a link to a mirror. Usually the post is moderated up quickly, and all I'm suggesting is some way for this information to propagate to the story posting, such as "[mirror here]" added to the text of the post. Obviously, this would have to be tightly controlled so that the goatse folks don't go crazy with it, so maybe it would have to be under the editors' or story-authors' control.
I would be happy to pony up a few bucks if these or some other minor features were added.
An example of research in user interfaces is Denim which aims to marry the advantages of old fashioned pen+paper design with the convenience of having the computer handle the details. The idea is to allow the designer to freely sketch with a tablet but also add hyperlinks between sketches as the design progresses. There's a sample of the generated mockup, but really the videos on the page linked above are really neat. They show a person using a tablet to do a sample design. The software also incorporates some other modern interface ideas such as the zoomable UI and the pie menu.
Here are some more links to discover if you are behind a transparent proxy. Presumably these will get around any IP spoofing that the proxy might do since they're intended for this and not just "What's my IP?" although I really don't know the details of how these work.
t =1
http://www.all-nettools.com/pr.htm
http://www.broadband-help.com/cm_diagnose.asp?ini
As far as applications, if you're using windows, there are a number of very advanced audio editor programs, like Cool Edit, Goldwave, etc. Try a search at one of the usual software download places.
Probably the most extensive DSP applications turn to something like Matlab, but that's hardly free.
For a unix-style solution, there's a package of tools here called pipewave which allows you to do very complicated digital signal processing using unix pipes. It follows the philosophy that you can do very complicated tasks by cascading smaller components using pipelines. Here are some examples from the above site:
Do not steal the focus, neither on startup nor for any sort of dialog box.
Respect my preferences. I do not have the default gray color scheme, so do not hardcode gray as your icon/toolbar/dialog background color, etc. Also recognise that I might have the taskbar docked on the lefthand side. I run across programs all the time that think that if they pop up a window at (1,1) it will be visible since the task bar is at the bottom of the screen.
Do not go against the sound effects or window animations that I have configured. I have some sound effects enabled, some disabled. Some people have no speakers or are at work and have sounds disabled. Same thing for window animation. I have most of it disabled, so don't assume that I enjoy those stupid animated "unrolling" menus.
Remember the window position/size and always open to the last state. I hate apps that are too dumb and must be resized/moved each time they are started. Usually this is related to the prior point about not having the standard windoze explorer configuration.
Do not use any pauses. Don't pop up an error window for 3 seconds (with no ability to make it go away) or some such nonsense.
Avoide the splash screen at startup. DO include a useful version number in the About dialog, with contact info and a website for updates. Avoid auto-detecting updates unless you are clear and upfront with the user before going out to the network.
Any time you report a filename in a panel or status display, please test your app with long filenames or filenames with multiple spaces. Often when processing files that reside in the "My Documents" folder, programs will try to report the filename but only output "C:\Documents and" when the file was really named "C:\Documents and Settings\Administrator.BOOCH\My Documents\Recorded Shows\file.avi". A related point, if you must abbreviate filenames to fit in a limited space, consider only showing the trailing bits (i.e. the actual filename and as much path as can fit) rather than the other way around, showing the higher level directories first and cutting off the subdirectories and filename.
Don't include the runtime if at all possible. I always respect a 500k install package over a 4MB one. Don't put any "common files" in my system32 directory if you can avoid it.
Use an intelligent installer. I want the program's directory completely removed when I uninstall, not left empty or with some small derelict file that the installer didn't know about. Same deal with the registry. Don't leave an empty key when your program uninstalls. I will disagree with other posters here, there's absolutely nothing wrong with using the registry intelligently.
I should not have to reboot to use your application, unless there are very special circumstances. Win2k is pretty good about this, actually. And for all that is holy, DO NOT make an installer that forces a reboot as the last step.
Tell the user what's going to be changed during installation, and give him or her a choice. The default for icons should be a directory under Programs in the start menu. DO NOT install an icon on my desktop or in my quick-launch bar without asking. DO NOT put your app directly on the start menu "root" menu.
Default install location should be Program Files, not a random directory off the root (like C:\MyApp) but in any case it should be presented as an option during install.
Do not add anything to my startup without asking. If I like your program and want it to run automatically at boot then I will either use a checkbox in your config screen or I will put a shortcut in the startup folder.
Don't litter my temp directory. Delete whatever temporary stuff you create.
You didn't mention anything about your hardware, but I had the exact same thing happen to me with the Highpoint 370 controller on a KT7-RAID motherboard. I rebooted one day to find that the HPT BIOS would say only "broken stripe." I figured my NTFS partition was toast. But there is a utility, raidrb, which I think is written by either Via or Highpoint. Anyway you just boot from a floppy and run it and it "reassures" the controller that the stripe is really ok.
a ds/utils/raidrb.zip
http://download.viahardware.com/faq/kg7kr7/downlo
There is some discussion of other methods to try if this one does not work in the Raid section on Paul's KT7 page. (Google search for "kt7 faq" for the url.)
See also DCC, the distributed checksum clearinghouse. It uses a fuzzy hash so that bulk emails with minor differences are caught. I think the details differ a lot but the idea is more or less the same.