real time signal analysis of output from an audio device

Question

I'm writing a test program that can detect pops/cracks/noise (unknown frequencies and duration) in the audio output of an audio device. The purpose of this program is to reduce human error and make the test more systematic.

The test consists of playing a pure sine tone (say, 1kHz) by the test device, and recording the analog output with a recording device. The minimum test duration is 8 hours and any artifacts present in the output will be logged and saved for future access.

Currently, my approach is as follows:

Sample Rate(playback device): 48000Hz

Sample Rate(recording device): 48000Hz

Windowing function : Hanning window

FFT size = total samples

1. Record 10 seconds of audio samples.
2. Apply window, run FFT on the recorded samples.
3. Record the next 10 seconds of samples.
4. Apply window, run FFT on new samples.
5. Compare both FFTs. If the frequency bins have similar power (to a set episilon), then the audio signal is clean. Otherwise, log the timestamp of this occurence.
6. Repeat steps 1-5 until 8 hours have surpassed.

A 1kHz sine tone, along with a 0.01s 3.5kHz sine tone that repeats randomly, is used as a test signal for the program. Unfortunately, my results have a high frequency resolution and it seems difficult to detect what is considered noise.

I am not well-versed in DSP and was wondering how I can improve the accuracy of my results?

Answer 1

I'm writing a test program that can detect pops/cracks/noise (unknown frequencies and duration) in the audio output of an audio device.

Pops/cracks are impulsive in nature and therefore quite broadband. noise is very broad but I would assume here that is anything additive to the sinusoid.

You can catch all three, given reasonable assumptions, using the same way that Total Harmonic Distortion (THD) is measured.

To do that, setup a very narrow band-stop filter, also known as a Notch filter, and apply it to the recorded signal directly. The cut-off frequency of the Notch filter should be exactly on the frequency of the sinusoid you are recording.

The signal at the output of the notch filter will contain everything except the sinusoid signal.

Which means that you would be able to capture cracks and pops, because they would spill across the spectrum as well as any additive noise to the signal.

To quantify the extent to which your signal is "noisy", you can then apply an envelope detector, which in your case is basically a moving average filter followed by a threshold.

The idea there is that you integrate the "residual signal" (what is left after you have removed the sinusoid) over a period of time depending on the sort of temporal resolution you want to achieve and then you threshold that quantity. Basically, if the total sum of the signal over 5 seconds (for instance) becomes larger than some threshold (similar to the $\epsilon$ you seem to already have used), then that time interval is marked as "noisy".

For a notch filter you can design one using plain simple pole-zero placement or use a Twin-T.

If the Q-factor of those filters is not satisfactory, in other words, if the Notch filters you obtain with these methods are not selective enough, then you can simply subtract the sinusoid at the input from the recorded signal. Of course, this has to be done "carefully" because any phase difference inserted in the middle would result in an offset of your $\epsilon$ and to cut a long story short, prior to subtracting the sinusoid, you would first have to make sure that its phase is aligned, in which case we are into the Phase Locked Loop land. The PLL will basically be generating a local sinusoid that is locked on to the phase and frequency of the incoming sinusoid and you can use that to subtract it from your recorded signal. This would make it probably the sharpest of notch filters.

You could of course sum all the bins except the bin that contains the sinusoid you are trying to measure but the challenging aspect there is going to be the resolution of the DFT.

Hope this helps.

EDIT:

Just as a note, I thought I would just say here that what you are doing there should be done in a multi-threaded application, so that the recording thread proceeds uninterrupted. When you write:

1. Record 10 seconds of audio samples.
2. Apply window, run FFT on the recorded samples.
3. Record the next 10 seconds of samples.

then, it is good to keep in mind that a single thread application would miss part of "reality" between steps 1 and 3 when it was processing the frame (but not recording). You can minimise this "gap" error by processing smaller chunks of audio but within limits. To truly do it in as close to real-time as possible way, you would need to have one thread recording sound and stuffing a queue with frames and another thread on the other side of the queue popping frames for processing.