QA402 Release 0.996

Releases for new SW are posted on github (see here for the QA402, for example). The 0.996 release for the QA402 adds a some more features, including:

  • Export multitone WAV
  • Multitone generation
  • AMP Frequency Response Chirp plugin
  • User weighting
  • Triggered Captures (aka Open Loop)

Export Multitone WAV

Multitone testing is an useful technique for testing amplifier linearity. When amplifier suffers from a non-linearity, it will manifest as a mixing product. That is, you subject the amp to two tones, and additional “phantom” tones will be created from nothing. There are formal IMD tests (see SMPTE and CCITT). Multitone tests take those a step further, subjecting an amp to dozens or even hundreds of tones simultaneously.

In the 0.996 release, you can create a multtone WAV at a 48K sample rate using the File->Export->Export Multitone WAV @ 48ksps. The options for the export as follows:


Be aware the RMS you specify is the average RMS–the peak will obviously be much higher. If you are generating two sine wave of different frequencies, and the amplitude of each is 1.0, then the maximum peak could be 2.0. And if you are generating 50 tones each with an amplitude of 1.0, then the maximum peak could be 50. As you specify more tones, the total RMS may need to be reduced.

You can also specify you’d like the generated tones to be nudged slightly to land in FFT bin centers, allowing you to use a rectangular window. The generated WAV can be played on whatever device you wish.

Multitone Generation

For the multitone generation out of the QA402, you select the multitone generator:


Right click on the button to bring up the context menu and set your parameters:


And the resulting spectrum in loopback (HANN window) appears as follows:

Note that the measured RMS appears as -25 dBV, the same that was specified in the setup. But the level of each tone is around -42 dBV or so.

AMP Frequency Response Chirp Plugin

The AMP Frequency Response Chirp Plugin allows you to quickly characterize the frequency response of a DUT in under a second. This is in contrast to stepping tones sequentially through the DUT and measuring the response of each. The setup for the plugin is shown below. The settings resemble the setting available in the Expo Chirp context menu:


Below is a sweep of a bandpass filter and several different smoothing options:

User Weighting

User weighting functions just as it does on the QA401. This allows you to apply a curve to the measured data. Some common scenarios include:

  • If you are working on a phono preamp, you can use the anti-response to “flatten” the curve of your circuit. Thus, ensuring your response is correct is simply a matter of ensuring the response is flat.

  • If you are facing some mains noise in your circuit you’d like to reject, you can build a custom weighting curve that notches out the response at the offending frequencies.

  • Mic curves can be applied in the user weighting, ensuring the overall response is flat.

There is a fixed curve for A-weighting, and user-defined curves for RIAA record and playback, and you can create your own weightings as needed. Below is multitone in loopback with the RIAA Record Response applied.

Triggered Captures

Triggered captures builds on the QA401 functionality. The common industry name for this feature is often “open loop” testing. But in a nutshell, this mode allows the analyzer to measure an external signal where the measurement start time is triggered by an external event, which is usually embedded in the stimulus itself.

If you are aiming to measure a constant sine wave or noise, then you don’t need a trigger. The signal is omnipresent and you can capture it whenever, analyze it, and repeat as often as you like.

But what if you have a device without any analog inputs and you want to measure a swept tone to learn the frequency response of a DUT quickly? For example, how can you learn the response of an MP3 player which has no inputs?

In release 0.996, there are two pieces added to enable these triggered measurements. The first is an exporter to build the special chirp. The second piece is the ability to wait for a trigger before starting an acquisition.

As an example, let’s say we want to measure the EQ in the Windows 10 Groove Music player. That is, we’d like to learn see what the EQ is doing when we adjust it as follows:


To measure the impact of the frequency response, let’s use an exponential sweep as a stimulus. First, we can decide the size of the FFT we want to use. Usually longer is better, but that might not always be practical. To understand the tradeoffs, first make some Expo Chirp measurements in loopback mode to learn how the FFT impacts your measurements at the band edges and to understand how windowing plays a role. For the sweep below, we started with File->New, and then set Expo Chirp, changed the level to -10 dBV, switched to rectangular windowing, disabled the right channel, switched to +6 dBV input, adjusted the FFT size to 32k and set the X axis to range from 10 to 30k. The response looks as expected for the 48K sample rate.

Next let’s export a chirp with a 32k FFT size.


The default parameters are fine:


The default export file name is fine. Embedded in this file name is the Bit Depth (32-bit float), the required FFT length (32K), the pre-buffer size, and the amplitude (-10 dBFS).


Opening the WAV in a wave editor such as Audacity shows the following. Note there are 4 distinct regions. The first is a region A with a greatly elevated noise floor. This is to ensure any noise gates on the DUT are opened. Region B shows the trigger burst, region C is a brief pause of 50 mS before the chirp, and region D is the chirp itself.

Next, let’s load the WAV we just created into Groove Music Player and verify the EQ is flat:


Right click on the Run/Stop button in the QA40x application to open the context menu. On the Triggered Acquisition page, click the start button to start acquiring samples from the DAC that Groove Music is using:


At this point, you’ll see a fluctuating level being reported in the progress bar. Note the trigger level has a default of -25 dBV. Whenever the captured signal exceeds -25 dBV, the acquisition will start and you’ll know this has happened because you’ll see a “Triggered” message followed by an display update. Next, play the WAV we loaded previously: The output shows as:

Switch to Time domain and look at the analyzer input. You should see a captured sweep (without the trigger burst we saw in the imported WAV). Note that the amplitude is constant over the duration of the burst, which means the frequency response will also be flat.

Next, let’s nudge the music player EQ midrange down 12 dB:


And now re-capture the same WAV:

Next, let’s switch the plot to dBR, and select the “display peak” as the 0 dB reference point. We can also change the scale of the plot to make the responses clearer:

And from this plot, we can see the center frequency of the mid EQ is 1 kHz, and that the depth of the notch is about 13 dB with some sidelobes that are likely indicative of a less-intensive algorithm used by the Groove Music player.

The exponential swept chirp is a very quick way to characterize the frequency response of a DUT.


Feel free to post any questions, bugs or observations here while using the 0.996 release.

Thank you for the frequent updates. The QA402 is a promising product, with the chance for digital I/O. (This is why I got it early, and have ignored the previous models.) Practically everything I build has at least one digital end…
While I2S is not yet there, it has to be open loop for now, a door which this update opens.

However, there’s a regression, 0.996 has broken the plain frequency response measurement for me. I tried back and forth, works with 0.995, but not with 0.996.

This is a frequency response plot of v0.995 with all default, just a pair of BNC cables from output to input:

(Left and right channel, but right is practically eclipsed)

This is the same for v0.996:

(Left is unusable below 100 Hz, right is crazy)

It varies with the sample rate, when using 96 kHz left is garbled below 200 Hz:

Again a different picture with 192 kHz:

The triggered acquisition is somewhat unstable for me. (And not useful yet because of above artefacts.) Quite a number of times I got this error message:
I found exception logs, two kinds, the first is some array out of bounds, the other says “DoAdcStreaming called when engine was busy”.

Besides this, I’d have a lot of bugging and nitpicking about the software in general (no offense), but don’t want to distract this thread.

Thanks in general, keep up the good work, it’ll get useful. :wink:

I too have not been able to get the FR to work in 996- running in my desktop PC. I checked the integrated amp I was testing with the 995 software which was running in my laptop, and it was fine. I reinstalled 995 in the desktop and it was ok. I stopped at that point. Here is what I got doing the freq response of the device using 995:

and this is what 996 gave me:

It is only a 30w/pc amp :grin:

Maybe there are some other settings that need to be set?? So far I am enjoying the QA402…

Hi @IDC_Dragon and @VAR,

I think I can reproduce: Can you see if the problem goes away with RECT window?

File->New, then press Expo Chirp, then adjust axis. Note Window is FlatTop by default:

Switch to Hann:

Switch to RECT and zoom to unhide red trace. Issue goes away. so it looks like windowing isn’t correctly applied to right channel. Will fix for 0.997.

Yes, same here. Does that mean that a FR measurement requires Rect window?
(Just tried to retest with 0.995, but it wouldn’t let me switch window, gives me that “QA401 Error” box. Nitpicking: wrong hardware stated…)

I installed 996 and had similar results to what you showed:
Flat top:



In my case it looks like windowing is not applied correctly to either channel except in the case of Rect. I am not sure I would see a difference in my measurements between the normally selected Hann window of 995 vs the Rect window of 996, but will do it as I am retired (for now) and like learning…Update- I ran the same test with the Rect windowing of 996 vs the Hann Windowing 995 and did not notice any difference. Also, I get this warning, but continue to run w/out any problems:

Release 0.9961 just posted which should address these issues. Link is located here.

Changes in release:

  • Visualizers were omitted in 0.996 and 0.995 due to config setting. Now fixed.
  • If acquisition is running when Run/Stop context menu is opened, it is now stopped. This will prevent the unhandled exception that occurs when triggered acq is started if already running
  • Windowing was not being applied to right input trace in FR mode, and thus for non-rect windows result was wrong
  • Certain measurements will now be suppressed if in FR. Rather than displaying a non-sensical number, “—” will be shown.

Now testing v0.9961 and v0.9962, I’m still struggling with open loop chirp.
v0.9962 seems to have a regression with the chirp file generation, the larger 2 FFT sizes crash on me (array bounds exception.)
OT, chirp has only the choice of 48 kHz or 192 kHz, however 96 kHz would be my sweet spot. Well, probably I could downsample it.
With v0.9961 I had the problem that the recording phase after the trigger detection seems too short. It captures only a part of the frequency range. With 0.9962 I get the impression I must not change capture sample rate, that might be part of the problem.
When being sloppy with the playback, it mis-triggers on the sweep instead of the 1 kHz pilot. The trigger seems not to filter on it, just goes by level?

Chirp generation fixed with v0.9963, thank you!

I have an issue left with recording/running it, probably uncovered by my misuse.
My DUT (DAC) won’t play 192 kHz yet, so I’m playing a 96kHz chirp. When running the QA402 capture with 192 kHz, there is ~50% chance for it to run into an array bounds exception.

Hi @IDC_Dragon

Release 0.99631 should address bug in larger FFT sizes, and also add back in the 96kHz export option. Please try here when time permits

With 0.9962 I get the impression I must not change capture sample rate, that might be part of the problem.

The timing of the chirp (burst length, silence gap, chirp duration, etc) should be same regardless of sample rate. And thus, you can export a 256K chirp at 48Ksps, and the play that back and acquire it at 192Ksps and it should work. Note, though, that the captured wave. EDIT: On second thought, this isn’t true. Because the chirp start/stop frequencies are different based on the sample rate. So, for it to work, you MUST match sample rate and length.

But the FFT sizes of the export AND the current settings must be the same. Please let me know if you see otherwise.

When being sloppy with the playback, it mis-triggers on the sweep instead of the 1 kHz pilot.

There is an issue of noise gating to be aware of. If the trigger in the wav is too short, then the noise gating in some equipment won’t open before the chirp is played (the Amazon earbuds almost completely filtered out the sync burst when it was 10 mS). Maybe some additional parameters will be needed to allow for different DUTs. But hopefully with the noise appended ahead of the trigger burst it will open most noise gates.

When running the QA402 capture with 192 kHz, there is ~50% chance for it to run into an array bounds exception.

Depending on how fast you grabbed the release you might have grabbed 0.9963 or 0.99631. I think that issue is fixed in the latter. Can you confirm which version you installed? Thanks

Yes, I was too fast, got v0.9963.
Now with v0.99631 the capture exception is gone, thanks!
(I’m a little afraid the latest version numbering may trigger a different out of bounds exception… :wink: