| Tips and Tricks for Debugging Audio |
By BDTI, 6/8/2007
IntroductionAre you designing a system that involves audio? Maybe an audio product or a product with an audio subsystem? Here are some tips and tricks that may help you.
Designing audio systems and debugging audio presents some interesting challenges. Sound is ruthlessly real-time; the speaker cone will keep moving, even if your prototype isn’t able to keep up with the flow of output samples required. The same is true of a microphone: the microphone diaphragm keeps moving and must be sampled often enough. If you skip one or more samples at the input or the output, then a (very loud) click or pop can result. What’s more vexing, the human auditory system, which is the final judge of audio quality, is extremely sensitive, especially to unexpected sounds (or artifacts) that your implementation may introduce.
Of course numerical techniques can be used to test an audio system. But the fact that we have two ears and love to listen to sound presents an opportunity. Thanks to evolution, our ears are designed to pick up unusual, sudden events in the environment. If you are developing and debugging audio, then you can use your ears to help guide you to fixing problems. This article discusses some of the ways to put your ears to work, and other tricks useful in debugging audio.
Set up an initial passthrough testWhen dealing with any signal processing application, but especially with audio, there are some ways to set up your debugging environment so that life is simplified throughout the development cycle, and even later when a new version of the product is to be released.
During development you will be using some kind of development environment. It may be a development board, with audio in and out. If the final hardware is not ready, you may use a software simulator (typically provided with the development tools for your target processor) to debug code. Using a well-constructed software simulator can provide significant advantages. For example, typically a software simulator allows disk files to be opened, read, and/or written. Whether using hardware or a simulator, if at all possible set up the development environment so that you can inject a test signal from a disk file and write one or more files of output data from your code. Instead of using standard .wav files, often the development environment requires that such files be in an idiosyncratic format. For example, it may require one audio sample per line written in ASCII text as a floating-point number ranging from +1.0 to -1.0; or one sample per line as a hex number. Sometimes two stereo samples are written on one line.
|
|
|