Has something in the software changed recently in terms of making frequency response measurements? I tested a stand-alone DSP processor last month, and there were visible oscillations in the bottom couple octaves to the point that I asked the manufacturer to double-check the units response against their AudioPrecision. I just finished another test and saw similar variations, including some at higher frequencies. These were not present in older software. I’ve tried adding averaging up to 10x, but they still exist. Any suggestions?
It might be too obvious, but did you try running with an older version of the software that worked??
Ha! Good suggestion! I’m way behind on work, so I’m panicky and not thinking straight.
Will try an old version asap!
Hi Dave, you can also just run a loopback check to verify things look as you expect. I just ran a loopback on the unit on my desk. Short InL- and InR-, connect L+ out to L+ in, and R+ out to R+ in. Then File->New. The press FR and change level to 0 dBV, then set Y axis to +/-1, then set X scale to 1 to 30K, then bump FFT up to 32K or so. You should see the following:
If you are testing a signal processor or anything with a DSP, it’s helpful to know the total delay imparted by the processor. That can be found by using the Automated Test->MISC Path Delay plugin. The plug-in will tell you the path delay (you can ignore the graph…just look at the X title
In the case above, I’m using a guitar signal processor with a delay set to 500 mS and 100% wet.
And then, with that 500 mS path delay, I can re-check the frequency response. First, let’s look in time domain:
In this plot, I first set the display to show output. Then I dragged Cursor 2 to the start of the output. Then I switched to look at input, and I dragged C1 to the start of the input to the QA403. There we can see the DX between the cursors is 502 mS. So, good agreement with the path delay plugin. But take a look at the arrows. Due to the long delay, you can see the output of the chirp was trimmed off the end (right arrow) and was actually picked up during the very beginning of the next measurement cycle (left arrow).
Delay such as this can cause big problems for FR measurements. And the tell-tale indicator is that there is activity before the low-frequency part of the chirp gets started (left arrow). The easiest way to solve this is to move to a larger FFT. For example, a 128K FFT will take about 128/48 = 2.7 seconds to run, and there is nearly 750 mS of silence at the end that could accommodate the longer delay (see arrow below):
but in the end, even with 500 mS of delay, the response looks reasonable as long as the tail isn’t getting cut off and ending up in the front of the sweep:
The other thing that can be cause problems is any noise gating that the processor might be imparting.
So, I think it would be helpful if you could share the input time domain of your captured FR response.
And as @VAR indicated, try an older version. I think the time domain will tell us a lot, however.
Thanks, Matt.
Indeed, these are DSP-equipped devices that are showing issues.
I just tested the response of the unit with a loopback this morning, and she’s ruler-flat, as expected.
I typically test at 256k to make sure I’m not cutting anything on the bottom off. A few of these units are -3dB in the single-digit frequency region.
I am seeing those same oscillations in the last response graph you shared.
I’ll post some time-domain measurements shortly.
Thank you, as always!
OK, here is the “formal” reply to your feedback , Matt
The loopback measurement isn’t quite as flat as yours up top, but it’s still adequate.
Using the new Path Delay measurement, I got this:
Here’s what I see in the frequency domain:
Zoomed more to show osciallations:
The time-domain measurement:
So, I figured out why I thought the issue was new. I used an audio interface with Room EQ Wizard to perform the frequency response tests. The REW test includes a “start time” signal in the sweep. That’s how I got graphs like these without the oscillations (that weren’t supposed to be there due to reactance’s of the load).
Hi @Dave_MacKinnon, thanks for all this data. OK, so the path delay is quite small–about 708 uS. There are some new tools coming in the next release to help verify frequency response on devices with very long delays (~1 second). This is mostly for musical effects processors, so my apologies for being in a long-delay frame of mind 
Your FR in loopback looks great.
The ripple you are seeing could be real ripple in the DUT. For example, one filter option in the ES9038 ADC has +/- 0.68 dB of ripple (minimum phase fast roll-off). This filter isn’t used in the QA40x, but I point this out to show what passband ripples could show up in real consumer products like your DUT.
In the last plot you show, you can also see the ripple at the higher freqs, but it looks like it has been smoothed. If you right clik on the Freq Response button, you’ll see the option to apply smoothing. But I think if you are using a large enough FFT (which you are), the ripples you see are probably legit and interesting to know about. Digital filter roll-off rate, stopband suppression and passband ripple are all tradeoffs designers must make. If you want fast roll-off and lots of stopband suppression then you will suffer with passband ripple.
As always, thank you so much for helping this, Matt! I want to make sure I’m providing my readers the most accurate information possible. Having the QA403 as part of the testing has been amazing!
I agree with Mat. These response curves are quite typical of fast roll-off digital low/band-pass filters. It’s really not that bad. Looking at the scale it’s well less than 0.5 dB. As the filter order increases you get less roll-off before the cut-off frequency, but more ripples. The same thing happens with analog filters - the math is all the same after allowing for the discrete transform. It’s just much easier to build high order digital filters, since component tolerances don’t enter into it until you hit the quantization limit.
The thing with computers and the ability to zoom into high-resolution data is the the messy parts of audio reality get revealed. Whether you can hear it or not is another question altogether.
1 Like