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 ([url removed, login to view]). 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.
This application needs to always read the most current data in the buffer (i.e. If an more than one frame exists to be processed, drop the older frame(s) and process the most recent).
This is a strange delay error. The delays remain in the 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 ([url removed, login to view] is stopped). 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*46ms=138ms).
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 removes the delays until they are introduced again but I cannot even tell when the delays are present!
The deliverable will be a .Net 2005 project with a [url removed, login to view] GUI (multiple projects 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 Project code 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. Thanks for bidding!