An audio analysis tool to configure any sound system with an equalizer. It compares the output of the system to the input of the system and allows you to use this data to perform final equalization by matching the results with actual DSP/EQ.
License: GNU Lesser General Public License v3.0
C 87.84%Shell 4.65%Makefile 4.61%M4 1.31%C++ 1.59%
The JACK callback should return as fast as possible but there is buffer filling and shuffling that occurs. This should be moved into the main thread or a new thread, along with the other processing tasks.
Averaging on the output trace is done when the GUI updates. If the GUI updates more frequently the trace will appear smoother. If the GUI updates less frequently the trace will appear less well behaved. This is not desirable.
Averaging should be done as part of calculating the auto spectra and cross spectrum. Resolving this will be part of resolving #18
This error appears after trying to run the BRP_PACU executable after the initial build (sans "sudo make install"). Running "sudo make install" fixes this, but means that after any UI changes, "sudo make install" must be run.
A while ago I tried to test BRP-PACU on a live system and myself and a colleague observed that the pink noise generator seemed to be lacking in the high end when compared to the pink noise generated by a Yamaha LS-9. The audio interface was a Digidesign MBox2.
The user must be able to specify what windowing function they wish to be applied to the input audio through the GUI.
The user must have at least two window functions to choose from. Currently Blackman is implemented and Hanning should be added. More functions would be nice.
Hi, and thanks for adopting BRP-PACU! I've been playing around with it many years ago, and when I wanted to resurrect it this week, I found it still required FFTW2... so I was more than happy to stumble upon your fork! It works very well for me so far. I would love to see a "coherence" graph (I think this is what most dual-FFT tools call it) that indicates how reliable each part of the computed transfer frequency response is based on if those frequencies are actually in the reference signal and how much correlation there is to the measured signal in that bin. At the moment, I frequently see a slight artefact at the HF end, which appears as if it's shelved up by about 10dB above 16k (disappears of course when using pink noise).
Additionally, having a way to display the phase portion of the FFT would be a great aid in tuning crossovers and time-alingning subwoofer stacks.
All the best, and thanks for sharing your work! Jörn