Testing DACs with QA401 generated *.wav files

Hi all, just getting into some DAC testing and not getting the results I expect. Take a look - what am I doing wrong here? Thanks.

file name

Hi @Chicago, what does your time-domain trace look like? That will let you see the actual sweep, and you should be able to see an amplitude modulation of the chirp envelope on the input that corresponds to the frequency domain.

Also, can you try it at 48k?

And just to check for others, your sample rate and FFT lengths have to match. I see your chirp is 192k sample rate and 256k long, and your setup looks to be 192k and 256, so that part looks correct.

Here’s another run of my little pocket DAC at 192K. Quite different from the 1st run.

…and here’s 48K

I’ve re-run this several times, 48K/256K is rock solid and 192K/256K is different every time.

Hi @Chicago These days I leave my QA401at fs 192kHz so not recently tried it at 48kHz. However I’ve had exactly the same issue as you. I never have found a robust solution other than this Bluetooth Amp Testing - #2 by SABristol, so just ended up rerunning the test until I got what looks like a reasonable result.

Hmmm. I’ve read those links and it seems the solution is to add a second or so of digital zero at the beginning of the wav file to unmute the DUT?

Thanks for the input.

Hi. I’d have thought zeros too quiet. I added a few seconds of something like -70dBfs of noise and then set the QA401 so it triggered on the louder -10dBfs chirp. Matt suggested using a sine if you’d rather. As I said before this workaround didn’t make it totally bulletproof.

Well… you might be right.

I made a file that has 2 seconds of “digital zero” added at the top, and have attached the resultant sweep thru a good DAC.

I can tell from the DAC display it immediately detects 48K and locks to it. But it looks goofy still, apparently it has a noise gate that doesn’t open until you’re well into the sweep? I thought “raw carrier” would wake it all the way up…

I’ve been trying to test the Arylic Up2Stream HD DAC recently and, like you @Chicago, could not get a sensible result when testing it playing generated wav files through WiFi.

I tried various things, including:

  • Changing Fs, FFT length and % dBFS
  • Inserting tones or noise into the wav file to wake the DAC
  • Using another DAC the sibling Up2Stream Mini V3

The only thing that changed the outcome was swapping from using iPhone / 4Stream App to iMac / Airplay as the source and concluded [aka ran out of enthusiasm] that the problem lies somewhere between the the player and the DAC.

This was about the best result obtained:

Most of the plots look like there is some sort of AGC at work and it has to get to so far into the squawk (>150Hz) to stabilise:

For comparison I tried an old Cambridge Audio DacMagic, playing one of the same wav files that didn’t work over WiFi through it’s USB interface and it worked every time:

Hi @SABristol, if you take a look at the time domain, it will probably show you what is going wrong. If you share your output and input time domain, we could probably see what the issue is.

Hi @matt

Not sure how conclusive this is going to be as it doesn’t seem possible to get consistent results.

Test 1:
FR plot at Fs48, Le32k, -5dBFS:

Here is the measured input in time domain:

Test 2:
FR plot at Fs48, Le64k, 0dBFS with a preemptive tone and volume not set at 100%.

And here is the measured input in time domain - the amplitude looks far too low.

Test 3:
Spectrum of music sample:

Time domain music:

Hi Simon, I can’t say for sure what is going on, but take a look at your first time domain plot:


Note how it looks like part of the first positive going cycle is chopped off. That discontinuity results in a giant splash of energy across the audio spectrum (it would sound a bit like a ‘pop’). So, that suggests the DAC isn’t waking up in time to render the first few cycles. And as a result, the pop distorts the expected spectrum.

In plot number 2 time domain, can we see the preemptive tone? I’m not sure. The preemptive tone needs to be ahead of the chirp that causes the trigger. The plot below is taken from the page HERE. Note that the WAV you export will have regions B and C, and region A is something you need to add. BUT, what you add needs to be high enough to open the noise gain but not so high to trigger. So, I think some comfort noise at -60 dBFS prior to the trigger burst (‘B’) can do the trick.

I think you are very close to getting the measurement you expect. It’s that lopped-off sine that is causing problems.

Hi @matt

I had another go at it, this time starting from scratch and it seems to work :grinning:

Generated a new chirp file and then added -14dBFS (0.2) 1kHz for 3 seconds.

The resultant FR of the Acrylic Up2stream Mini V3 with the optional ESS9023 DAC:

It now seems to be a repeatable test. For some reason the short chirp visible at 3s wasn’t in some of my earlier files so this may have been the problem :thinking:

The 16KHz upper limit is no surprise with this particular module. Bass response is odd. I don’t know if it’s real or not. Interestingly, Arylic’s HD module also seems to have the same bass response.

As an aside, I generally use the QA401 with single ended inputs and outputs as most vintage equipment I repair has unbalanced RCA i/o. As such I use BNC<>RCA leads. Should I make up some leads that connect the QA401 pair of balanced i/o to an RCA to get better noise performance / CMRR?

Thanks for your help.

1 Like

I’m also having my woes with measuring the digital chirp to test DACs and DSP crossover. Having the same sample rate and FFT size is a must, like said.
@matt First, there seems to be a bug with the file generation (v1.442). When I generate a file with 0 dB full swing, the waveform is in fact clipped. Using -3 dB gives me full swing, so I suspect a wrong factor internally.
Second, it would be great if the capture would trigger on the right channel when using it as a reference. The left DUT channel is too inaccurate when measuring something far from linear, like subwoofer or tweeter channels. However, we may then be responsible to time-align them, or is the software smart enough to correlate the frequencies?
Third (nitpicking) it would be great if the file generation would remember the path, so next time I wouldn’t have to navigate all the way again. (A general annoyance whereever the software is selecting files.)
Fourth (hoping) it would be a breakthrough if the I²S output of my QA402 would be useful for generating a live stimulus, obsoleting to fiddle with external files and hoping for correct trigger.

@SABristol would you be willing to outline in a little more detail how you have developed a repeatable process?

1 Like

Thanks for reporting! This will be fixed for 1.148 (should be out this week).

It’s a good point to consider about triggered sweep if you are trying to test a sub. Would it suffice if the export option allowed you to specify a 100 Hz or 1 kHz trigger tone?

We will address the Path issue on the wav exports for 1.148 too.

It may fix that particular use case, yes.
Could the receiving end handle both without knowing upfront? A 100Hz trigger would give you a rather soft slope instead of an edge, no accurate timing. On the other end, there may be channels which transport neither 100Hz nor 1kHz well, like an ultra-tweeter crossover, some band pass, or a non-acoustic technical measurement.
You don’t like the option of triggering on the right reference channel, if avail? Admitted, this is a more complex measurement setup and not the general case.
I still hope to lobby you towards bringing the digital output to good use, resolving this for newer hardware.

Speaking of bugs, found another in the context: While tweaking finicky trigger levels I found the level control is left disabled after a measurement. It only returns enabled after pressing “cancel”.

Thank you for caring!

I think it would be very straightforward to trigger on either the left OR right channel. How much processing delay do you expect? Can you explain the exact signal chain? I think you are describing WAV->DSP crossover, that might have 50-100 mS of delay, is that right?

I was using two identical DACs (which may be an unusually recourceful case), one for your original test signal, one for the DSP output from it. Each is feeding an input of the QA402.
100 ms is already a lot. My system has a few millisiconds. However, can’t speak for everybody. FIR filters or convolvers are notorious for latency.