Previously I released a basic RTA that built around ALSA and Gtk to address the lack of audio test tools for Linux. That was a revisit of code I had from a long time back, and now in addition, I am releasing the swept sine wave analysis application which I have updated in a similar way.

RTA vs Swept Sine

An RTA is an ideal tool for quick checks and getting EQ into the right ballpark in minimal time. It doesn't show a huge amount of detail (it's only ¹/₃ octave), but often that's what you need when you are setting up a system quickly, besides any reasonable quality graphic EQ will also be ¹/₃ octave. Detail would only get in the way of sorting the fundamentals, and the effect of a room can be dramatic - no point in looking at all the detail that you can't put right without tearing apart the room and rebuilding it.

On the other hand, there are times where the detail is important. A swept sine wave can give a lot of detail which can show up things like standing wave effects, and even enable distortion measurement.

Both an RTA and Swept Sine analysis are useful, but for different stuff.

Working with Swept Sines

The first thing here is that analysis is far more detailed so is unlikely to be examined in real-time. It's useful to be able to store the measurements and examine them in detail at a later time.

Like with the RTA it's convenient if we can separate the stimulus signal from measurement. Why this is important is that we will often encounter devices and/or systems where we can't get a signal directly into them, or we want to measure the complete signal path. For example a car stereo may be able to play CDs or audio file via a USB device, but may not have a convenient way of connecting a sound device to generate the test signal and measure it simultaneously. In this scenario we want to be able to burn a CD or drop a .wav file on a USB device and measure the result independently.

To achieve this there are two parts: a sine sweep generator that creates .wav or .flac files plus an analyser which can read .wav or .flac files, identify the sweep and extract the useful information. This means that we would play the generated file (via whatever format, eg. CD) and record another audio file from our measurement device(s).

For example, to record from our sound device to a file suitable for analysis we could use something like:

$ arecord --device=hw:2,0 --format=S16_LE --rate=48000 --channels=2 --vumeter=stereo measurement.wav

Where we can connect the sound device directly, in another terminal we could playback the stimulus, stopping the recording process when done:

$ aplay --device=hw:2,0 sinesweep48k.wav ; killall arecord

Finding the sweep

The analyser runs through the file it is given and runs a windowed FFT on it section by section to identify the sweep. It uses various algorithms to work out the rate (assuming an exponential sweep to match normal log frequency scales) and position of the sweep in the file while detecting and ignoring noisy or potentially unreliable sections.

This allows the analyser to adapt to different rate sweeps and other situations.

Noise immunity

Once we know the location and frequency at any point in the file, we pick only the bands around that frequency from our FFT which acts as a narrow band filter excluding any background noise that may be elsewhere in the band.

This doesn't exclude all noise, but helps. For example if there is a major road nearby you may find you get a whole lot of background noise around 30Hz. This will affect the measurements around 30Hz, but away from 30Hz this will be excluded and not affect the measurements.

Distortion

One by-product we get from running the FFT is that we also can extract harmonics relatively easily. The analyser will sum the energy contained in the first few harmonic bands in the FFT and produces a second graph of this.

It's worth noting that this includes harmonics produced by measurement microphones, pre-amps and the sound device used to record. While it may be easy to discount these, you may be surprised what you get looping back the audio device alone. In my case the M-Audio MobilePre I am using is giving around 0.2% at low frequencies rising to 0.3% at low-mid frequencies and then falling 0.03% at mid-high frequencies. I don't know if this is typical for this device or if my one has degraded (eg. from Phantom power affecting the input devices).

Also, for those not experienced with distortion measurements of speakers, the numbers may look really high. The reality is that it's possible to have relatively high levels of low order harmonics produced by speakers without severe effects on the sound. Natural sounds are full of low order harmonics anyway.

On the other hand, amplifiers which often apply high levels of feedback may have low overall distortion figures but have far more unpleasant distortion mechanisms that produce a larger proportion of unnatural high order harmonics and these may have far more unpleasant audible effects.

Where measurements are made in an environment where there are other objects (eg. typical domestic environment), other objects may be excited by the sound and themselves produce harmonics which will also be measured.

Screenshots / Examples

A guitar speaker driven with a flat response amplifier (not a typical guitar amp) produces this response:

The lower graph is THD (Distortion) and shows clearly high levels of distortion. Guitar speakers are typically designed with no overhang on the voicecoil and so inherently produce large amounts of distortion. The additional detail produced shows two narrow gaps in the response with downward spikes. I believe these are resonances in the undamped cabinet or a multi-path effect causing cancellation at these frequencies.

A 2-way speaker system measured from the listening position (room acoustics having a major effect) produces this:

The response show the room is having a significant effect with the very spiky response being typical of all the reflections in a typical room. The smoothing setting may be used to reduce these if needed. Distortion is significantly lower than the guitar speaker, especially at higher frequencies where the lower excursion and risk of causing other objects in the room to vibrate and produce harmonics is significant.

Before someone comments on the lack of grid on the distortion graph, GtkDataBox stores grids on global variables internally and so where there are multiple graphs there is only one grid. In this case the frequency response grid is not suitable for the distortion graph so I have been forced to leave off the grid. If I have time at some point I may look at adding my own multi-grid workaround but for now the distortion graph will have to be gridless.

When you save the data to a .csv it also adds the levels of the first few individual harmonics for more detailed analysis.

FFT Windows and Distortion

In the case of the Swept Sine analyser, I provide a number of possible FFT window functions commented out in the code. Different window functions have a large effect on the effective cut-off of the FFT, effectively how narrow band it will be, and what the effective stop-band attenuation will be. For more detailed information see the Wikipedia article on window functions.

The choice of window function will have little effect on frequency response measurements assuming the test signal is distinct from noise, however dramatic effects on distortion measurements are to be expected, especially at lower frequencies where few FFT bins separate the fundamental and harmonics. The underlying problem is that the attenuation of the fundamental at the harmonic frequencies with popular window functions such as Hamming windows is relatively poor and may give you a distortion figure of >1% with a pure signal at lower frequencies.

The effect of different window functions is clear from running the analyser on the (pure) stimulus signal:

Hamming Window

This is a popular window function and provides relatively poor discrimination across the whole band and limits distortion measurements a relatively high floor.

Hann Window

Another favourite window function and the default for this application. Hann windowing provides improved discrimination for all but the lowest frequencies. This is likely a good compromise between response and distortion accuracy.

Blackman Window

We are now seeing more usable lower frequency limits with the distortion floor dropping off from 0.1% above about 50Hz.

Nuttall Window

This is by far the quickest drop off of the windows available and provides the best distortion floor at low frequencies. It is however showing some problems in the frequency response with this ideal signal.

Other tricks

One option where measuring low frequency distortion is important is to use a longer window length to provide more bins between harmonics. This can be done with command line options. I would suggest combining this with slower sweeps to ensure the purity of the signal in the FFT window.

Building / Running

Like the RTA, this will require a version of GtkDatabox that supports grid arrays - I snatched the source from Ubuntu Oneiric and build that on Lucid (I prefer to stick with LTS for stability).

Other than that make sure you have all the needed development libraries and run "make". This will build both the RTA and these Swept Sine tools which are now part of the same package. Depending on your platform you may need to tweak some paths in the Makefile.

If you are using Debian / Ubuntu then there is initial packaging support for packaging and you can run "dpkg-buildpackage" to build a native package (.deb).

Download: Auto Test Tools source

Download: Audio Test Tools amd64 .deb

For mono audio files you can run the analyser directly:

$ sinesweep_analyser testfile.wav

If there is more than one channel then you need to specify which channel to analyse:

$ sinesweep_analyser -c 1 testfile.wav

Additionally you can specify a custom FFT window length:

$ sinesweep_analyser -c 1 -w 16384 testfile.wav

Note that this will also use .flac files which are often a good choice as they are lossless and test signals compress particularly well.

Generating test signals

A swept sign generator is also distributed and allows you to generate your own stimulus files to play directly, burn onto CD etc.

A basic stimulus at 44.1KHz / 16bit stereo can be generated with:

$ sinesweep_generator stimulus.wav

To customise the file further see the options available by running sinesweep_generator without any arguments. For example, to create a 48KHz mono file starting at 1KHz (eg. for testing tweeters directly) you could use something like:

$ sinesweep_generator -r 48000 -c 1 -l 1000 stimulus_tweeter_48k.flac

Other options include specifying the time per octave of the sweep and bit-depth.