Phase and "coherence" plots?

[nettings]

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

[corinfinite]

Hi Jörn, you can thank @fhaust for the upgrade to fftw3 :)

I haven't had much time to put into the project but I'm hoping to have some time in the next couple months for audio software projects.

I wholeheartedly agree with your suggestions for a phase and coherence plot. I am not very experienced with the details of a lot of the audio processing that goes on in dual-FFT so I don't know how easy it would be for me to tackle.

I'm not sure of the shelving issue is related to this but issue #19 describes an issue I've noticed with the pink noise generation. It's an issue I meant to open a while ago. I've not been able to perform any sort of verification work using BRP-PACU alongside a commercial system like Smaart or SIM3, perhaps doing that would shed some insight into the issue.

[nettings]

Hi Matthew, great to hear from you! I have commented on #19 as well. For instrumentation, I recommend the JAPA and JAAA tools by Fons Adriaensen (if it's not in your distro, you can find the sources at http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html). I'm also using roomeqwizard a lot (http://roomeqwizard.com), but since it doesn't support jack, it's a bit of a pain to use with professional soundcards. I'm going to solve it by getting a two-channel USB interface specifically for it and connecting it via analog XLR to my MADI universe (goes to show how much hair I lost over jack and ALSA loopback routing)... :-D

[nettings]

A slightly idiosyncratic implementation but with very well-behaved noise output is http://kokkinizita.linuxaudio.org/linuxaudio/downloads/jnoise-0.6.0.tar.bz2 , again by Fons Adriaensen. It's also GPL v2. Maybe we could just plug it into BRP-PACU. I will take a look.

[corinfinite]

FFTs are not my forte but from some of the initial reading I have done phase should be easy relatively straightforward to implement from the existing FFT code. I don't know what it would take to make a coherence trace or the technical term for a coherence trace I would use to begin researching it.

[nettings]

Basically, that "coherence" plot also has a spectrum axis and one "trustworthiness" axis, between 0 and 100%. A trivial approach is asking "is that frequency bin actually in the content we're listening to?", e.g. if we're listening to a solo flute, the bass range result would be basically bogus, although the transfer function algorithm would still be spitting something out. But additionally, the question is how "tight" the connection is between the reference and the measurement mike - it could happen that the room adds a lot of reverberation (which in the case of room modes might be very narrow, but with long ringing spikes over an otherwise shorter RT60). IIUC, this is tackled by measuring the correlation between ref and mic. Low correlation == low trustworthiness. I'll keep an eye out for textbook implementations...

[corinfinite]

Dual Channel FFT Analysis (Part I) from Brüel & Kjær is a good resource but I struggle to connect the math to code in BRP-PACU. For example the coherence function appears straightforward to implement but I haven't figured out if the auto spectra or cross spectrum (S_aa, S_bb, S_ab) exist in any form within the code to calculate it, nor have I found an example of what calculating those functions is like in code. The relevant code for this question appears to be in fft_capture function in testfft.c

This excerpt from Handbook of Signal Processing in Acoustics is another good overview. BRP-PACU doesn't do any windowing at the moment, but that should be a quick fix.