Chapter 27. Case Study: Signal Processing

Lisa Simpson: Would you guys turn that down!

Homer Simpson: Sweetie, if we didn’t turn it down for the cops, what chance do you have?

The Simpsons “Little Big Mom” (2000)

Acceptance tests for a real-time signal processing system are presented in this chapter.

It’s Too Loud

I have produced software with Richard Cann of Grozier Technical Systems for a number of years. Grozier produces sound level measurement systems. Numerous concert sites, particularly outdoor ones, use these systems to monitor sound levels for regulatory reasons and to act as good neighbors.

The systems are composed of embedded systems that run multiple programs. Richard produces some of the programs, particularly the display and control components. I produce the real-time signal analysis portion [Wiki08].

Sound Levels

The programs input the sound through the microphone input. Each second, 22,500 samples are recorded. The signal analysis programs perform calculations on each of these sets of samples. The output is a measure of loudness, (technically the equivalent continuous sound level [Leq]). An overview of the process is shown in Figure 27.1.

Figure 27.1. Sound Level Process

The sound is input through a microphone. The gain (how much the signal is amplified) varies based on both the microphone and the volume setting on the input. To correctly compute the Leq, you must adjust the gain so that a standard sound source (a calibration source) produces a specific Leq result.

It is difficult to replicate the entire system (microphone, calibration source, and so forth) for testing. However, you can capture the sounds by using regular recording methods and then replay them as input (a test double) for the tests. Suppose the sounds produced by the calibration source are captured in a calibration file and sounds of known Leq are captured in separate files. These files contain a second’s worth of data (22,500 samples). Then the test of the overall system can be as follows.

To ensure that these Leqs are correct, the same test is repeated with calibrated specialized hardware. The results of the hardware test become the oracle—the agreed-upon expected result. This is similar to using the outputs of an existing system to be the expected results for a new system.

Developer Tests

The details of the process are shown in Figure 27.2. It shows that there are two intermediate results in the computation: the windowed samples and the A-weighted samples.

Figure 27.2. Details of Sound-Level Process

Richard is particularly interested in the final results. Is the Leq computed correctly for a particular file? As a developer, it helps if I can apply tests to intermediate results. These intermediate tests are usually termed unit tests because they apply to lower-level modules. However, because Richard is highly experienced in signal processing, he creates input and output files that can be used in acceptance tests for the intermediate processing works. For example, for the Compute Leq part, he creates an A-Weighted sample file.

The input and output files contain digital samples for 1 second. Equivalent files are available for each of the other steps in the process.

Summary

• Acceptance tests do not have to involve just simple values. They can be entire sets of values (often represented in files).

• A subject matter expert can often create lower-level tests that can be used as developer tests.