Microphone Input Monitoring Delays Problem

I am experiencing a problem with a project that monitors the microphone input. In this project the reaction time to the sound input is critical. The base for the code came from a project found on Code Project web site "Sound Activated Recorder with Spectrogram in C#" ([login to view URL]). The original C# waveIn API wrapper was written by Ianier Munoz. "A full-duplex audio player in C# using the waveIn/waveOut APIs" ([login to view URL]). The problem with both the example project and my code is that "delays" are creeping into the application when systems experience demand overload. On faster computers this is not a problem and the delays do not appear, but for slower systems this is a problem. If you look into the code, changing the num of buffers used does not seem to affect the delays once they are introduced. I am using a small buffer size to acheive a small delay time. Public Const m_BUFFER_SIZE As Integer = 256 Public Const m_SAMPLING_RATE_HZ As Single = 44100 / 8 If the recorder is stopped and then started, the delays dissappear, but automating this is not an option for several reasons including the fact that there can not be any pauses in the monitoring of the signal. This application needs to always read the most current data available from the sound card (i.e. If more than one frame exists to be processed, drop the older frame(s) and process the most recent). This is a strange delay error. I have been trying to understand it for a while. The delays remain in the microphone input (waveIn) signal even if the system is stressed monentarily and then has time to recover. The test for delays I usually use an older computer, start the sound catcher program, then start a virus scan. If the system is stressed enough delays appear, and they do not disappear when the stress on the system is removed ([login to view URL] is stopped). After the delays have been introduced you should be able to tap the microphone and observe the delayed response from the software. The amount of delay typically experienced (around 900ms) can not be explained by the num of buffers used (3) and the length of each buffer (approx. 46 ms : 3*46 ms = 138 ms max data stored in buffers). I am not sure where this extra delay data is being buffered or how to detect if the signal being monitored is delayed. This understanding is at the heart of this project. Again, starting and stopping a recorder (freeing buffers and re-allocating them) removes the delays until they are introduced again but I cannot even tell when the delays are present! The deliverable will be a VS 2005 project with a VB.Net GUI (multiple projects in other languages in a single solution ok) that implements a version of the Sound Catcher program that handles system overload well and is immune to delays once the system is not stressed (recovers nicely). I understand that delays are unavoidable some times at peak stress levels but the deilvirable needs to always be delay free if the systen is not stressed. Display smoothness and minimum use of system resources are desired to accomplish the smooth handling of system overloads. Before bidding on this project please download and run the code listed above and confirm that you have the necessary (slow) hardware to experience the problems described here. Make sure you are positive you have a solution as well. After accepting the project I am looking for someone who can finish it in one weeks time. Thanks for bidding!