BRP-PACU Version 2.0.0 Released Today

Its been a while since I posted anything about BRP-PACU, a dual channel FFT based Acoustic Analysis Tool to help engineers configure professional sound systems.  I have been using it regularly, but I recently became motivated to improve it.  Here is a list of improvements obtained from the Changelog.

Screenshot of BRP-PACU version 2

Basically now you don’t need an external pink noise generator or a dual channel capture card.  Just one input should work fine.

Version 2.0.0 Pink Noise and Jack Support (allowing possible Mac OS-X support?)

• Update on Mac OS-X, my wife’s laptop hasn’t got enough disk space to install macports, xcode, etc, anyone out there who would like to check it out though let me know.
• Also I need help packaging this for the OS-X and for Linux (deb).
  

I have a minimal Debian & Xfce based vmware image, which will run on any x86 Mac/Linux/Windows, though.  Not sure how to distribute +850MB of data yet, as ISP’s tend to limit upload bandwidth to a trickle.

Added Pink Noise Output and  the ability to Un/Mute and adjust levels

Added Jack Audio Connection Kit support and removed Alsa (removing need for linux)

• Automatically connects Reference and Measured inputs to Channel 2 and Channel 1
• Automatically connects Pink Noise Output to Reference Input and sondcard output
• This app may now run on a Mac since alsa has been abandoned.  This may require some tweaking.

Major GUI and UI update!

*Delay function now resets delay before each capture, resulting in a much
more intuitive delay finding procedure.

*Rewrote buffer capture interface so that it makes more sense and works
consistently.

*Rewrote keyboard shortcuts so they don’t interfere with the Avg gain.

*Added default zoom button to return to original zoom settings.

*Added inserted delay size status on the status bar.

*Added “about” and “general help” windows

*TODO: ability to save buffers to a file.  Also a VM for windows and Ubuntu packages.
Miscellaneous Bug Fixes and updates.

Advertisements

BRP-PACU Most Major Update Ever, File Release At Last!

File Release!!

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.

Todo:

• 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.

BRP-PACU

Update! fixed link that sourceforge somehow broke.

BRP-PACU

Brian’s Reasonably Priced Professional Audio Configuration Utility

Audio Engineering With Linux Part II

File Release today! The code is GPL. To all you MS windows folks out there this means the program is free as in it costs $0. It is also free to use, distribute or even sell, but the source code must be included (upon request) and it must retain the GPL license. Contact your lawyer for more details on legal redistribution.

Un/fortunately it will not run under MS Windows, unless someone decides to modify my code to do so. I may decide to distribute a Linux VMWare player image so that MS Windows folks can use it. There won’t be a huge quantity demand for this software, but those that have a use for it will be desparate enough to use a virtual machine. If someone would like to donate money I will port it to MS Windows. Make me an offer.

Here is a brief description of the project:

Currently there is only overpriced Live Acoustical Analysis ($600-$1200) software capable of performing the transfer function of FFT’s for sound system configuration. This is ridiculous considering the trivial nature of the concepts, but understandable since there is only a limited audience. There does not seem to be an Open Source Version available. And there definitely is no software available under Linux.

This project is written for engineers who configure professional audio systems. It’s main feature will be the ability to take multiple sample transfer function plots (output FFT / input FFT), average them together, and flip the averaged plot to aid in final equalization. Nearly all Professional Audio Engineers use this function now rather than the older Real Time Analysis method because it is quicker and just as precise. This technique is powerful and quick, but very difficult to master, perform properly, and requires a special microphone and mixer to do correctly.

This project will also be able to provide a simple FFT plot to aid in finding room modes and quick audio verification.

This Project uses the FFTW package, libgtkdatabox, GTK+, alsa, and is programmed in C, and runs under Linux.

I currently have a dual threaded program, one which collects audio data, and one that performs the FFT and plots the results. It currently is a full featured audio analysis tool capable of finding the delay automatically in a system and is able to find both the transfer function and the impulse response of an audio system.

Audio Engineering With Linux

Update!

This project will use the alsasound (audio), libgoffice which is used by gnumeric (plots), and the fftw (fast-fourier transform analysis). This project will use these three libraries and gtk (for the gui). There are many different ways to perform this task, I chose these packages because of my experience with all of them. I am using the M-Audio Mobile Pre USB for audio I/O. Laptop soundcards stunk and typically only have one input, but if used properly, it may be possible to do this project with one input.

I am a Linux user. I use Ubuntu 6.10. I have tried other Linux distros and I currently run several. But my main laptop, is Ubuntu. This is a problem/challenge to the real world and the workplace, as most software is written for MS Windows. An example is <an unnamed pricey proprietary software package>, an audio diagnostics tool.

I usually use this pricey proprietary software package to calibrate professional sound systems using its “Transfer Function” feature (output over input). It works very well and is quick to perform, but very difficult to set up and actually perform accurately. The basic idea is that I need to be able to view the output of my sound card divided by the input to it, in the frequency domain usually done using the FFT. I have written a program that takes samples from the mic input, and send data to the line out. I have also used the fftw library to analyze samples. I have even written a few small GTK (a nice gui toolkit) programs. I think I can pull it off, but it will take some time. I am an old school C programmer. I have used many languages such as PHP, Python, Perl, but I always come back to C.

What I am going to do is write a simple GTK based program that allows me to perform the transfer function on a system. It will need to take several samples at different room locations and average them together so that I can use them to calibrate the system. It will need to be able to time-align the frequency data (delay) so that we end up with accurate curves.

Assuming I am not violating any software patents, I will release the project under the GPL on sourceforge. I have looked for a similar open-source project but it doesn’t seem to exist yet.

As I always do for any design, I will Sketch it out Before Coding™. This helps me avoid a complete rewrite midway through the coding.