For those of you new here, BRP-PACU is an open-source program capable of real-time audio analysis of professionally installed loudspeaker systems. The idea is to use a calibrated microphone to measure the response of a room to playing a reference signal which is usually pink-noise but could be Pink Floyd, as long as it has decent spectral characteristics. The measured signal gets fft’d and divided by the reference signal’s fft. This is captured at 3-5 locations. These captures are then averaged and flipped, then used to calibrate the system.
If none of this rings a bell you probably should read some of my other post topics, because this stuff is probably gonna bore you.
It uses GTK+, alsa-lib, gtkdatabox, fftw, and more! Many of the algorithms were first tested and simulated with Gnu-Octave. Sorry windows users, this requires alsa so tough luck, but you could try it under VMWare, VirtualBox, or Qemu, or even an Ubuntu dual boot.
From my Project News page at sourceforge.net:
Posted By: electronjunkie
Date: 2007-10-09 12:30
Summary: Current Project Status I have made significant progress now with this project. While it is still not usable in its current state, it does the following:
- Displays FFT of Blackman Windowed audio input in real-time.
- Displays the transfer function, H(f) = Y(f) / X(f), of the measured system (channel one divided by channel two, or output (measured) divided by input (reference)), where X(f), Y(f) is the fourier transform of the output and input respectively.
- GUI now uses the quick excellently documented gtkdatabox library instead of the scantily documented libgoffice. Great Success!
- Averaging function for the H(f) frame, so graph doesn’t bounce/jump in time and smoothing of the plot to make the data more readable by humans, ex: H(f) = (H(f-1) + H(f) + H(f+1))/3.
- Impulse Response now works! h(t) = H-1(F)
*Output is in dB and Octaves like humans hear, as opposed to Voltage and frequency in Hz, with actual frequency in Hz displayed under mouse cursor.
- Add channel 1 & 2 signal indicators
- Add support for more than the 4 + averaging buffer.
- Add save as support (so that a session can be saved). This is something even the expensize programs like SMAART do not do. How many times have you sampled a room just to have SMAART or your PC lock up and lose your buffers. It will also allow you to save samples for future reference.
These items are actually trivial to implement. As an engineer all the fft/data related processing is easy to me, the hard part has been the programming read tape (fixing Makefiles to include libraries, using the libraries API’s). But I have learned some excellent concepts along the way.
Currently we are using one thread for the gui/fft app and one thread to obtain the audio. I’ll probably separate the gui from the fft thread, so that I may change the audio thread to a callback instead of polling. Right now I just want to make it work, then I will optimize the coding later.
The code will be released at version 1.0, as it will not be released until I have tested for memory leaks, and actually used it to calibrate a sound system. RT60, and other measurement features will be available in later version releases.