Is there a way to measure the latency of a digital audio device with the QA401? Currently, I use a single-cycle burst signal and measure the delay time on an oscilloscope, comparing the time difference between the generator signal and the output of the DUT. I guess as an alternative to an automatic measurement, can I create a single cycle burst on the QA401, and then measure it the usual way?
Hi @voltist, the main screen of the QA401 will report path delay when making single-tone measurements. If you can’t see the 5th column of data, then widen the application a bit and it should pop into view. The delay is calculated based on the difference between the output reaching 50% of max and in the input reaching 50% of max. So, if you are measuring something like a compressor that is changing the dynamics of the tone burst then it might cause an issue. Similarly, if you are measuring an audio delay that mixes the dry and wet signals, it might also cause an issue (see later in post).
If you are testing a signal with a lot of path delay (more than a 10 or 20 mS at 48K) then you might need to dial up the “prebuffer” a bit in the Settings. This specifies how much extra “tone” must be generated to ensure it is captured after the appropriate delay. As you can see in the UI below, the QA401 can cope with up to 672 mS of path delay so that testing things like Bluetooth is possible. The downside to leaving this setting at max all the time is that it slows your measurement update rate.
If you have an audio source that mixes the dry (non-delayed) and wet (delayed) signals together, you can’t rely on an automatic derivation as above. In that case, you’ll need to switch to time domain and try to estimate the delay visually. More on that in a bit.
Continued…
If you are trying to determine the delay of a DUT where the delayed signal might be mixed with the original signal, that is best done in the time domain. A guitar pedal is a typical case here.
Take a look at the time domain of a guitar delay pedal:
Region A is the ramp of the QA401 burst output. Region B is the steady-state of the burst. The leftmost arrow above marks the start of the steady state, and the rightmost arrow marks when we see a delay version added to the original signal. This is about 7.5 divisions between the arrows, with 5 mS per division, so the delay in this case is 35 mS.
When checking delays, if you just let the QA401 run non-stop then bursts will overlap as the “tail” of the DUT spills bursts from one measurement into the other. So, use the +space on the QA401 to emit a single burst. This will ensure the delays can die down between measurements.
To measure much longer delays with mixed signals (dry and wet), you’ll need to rely on a longer FFTs. A 256K FFT at 48K will take about 256/48 = 5.33 seconds, so that sets your delay upper bound. Setting the pedal at max delay and using a 256K FFT size yields the following:
At 200 mS per division, we can see the delay time was 600 mS.
Thanks, got it. The known latency is 2.6mS - I had to set my test frequency to 100Hz, then the QA401 reported it. With a test signal of 1k, the delay was reading about 700uS.
I’ll try measuring delays tomorrow - thanks for the help!
That’s curious that is worked at 100 Hz but not 1 kHz. When you get a moment, could you share a plot of the output time-domain where you are seeing a bad result? That will let you see the output (in bright yellow) and the input (in very dim yellow) and hopefully we can see why the algorithm missed it.
Below is a plot in loopback, and you can see the ~11 uSec of delay that’s being reported and the bright and dim traces.
Thanks! Matt
