On 25.02.18 21.57, Sebastian wrote:
> I wonder if you can separate the delay measurement from the sweep
> measurement?
> Think of it as some kind of calibration step where the rough timing of
> the sound card is estimated.

No, this is not required. Since I sample my own reference and the 
response simultaneously with the left and right channel only the 
/differences/ between left and right channel need to be calibrated. This 
is quite easy, simply measure with both channels connected to the same 
reference.
Most of the time no calibration is required because the differences 
between the two channels are typically very small.

> You would need a sync signal with good
> auto-correlation properties. You than can even do the processing offline
> if all you are doing is recording some seconds from the sound card where
> you expect the sync signal.
> If you than have the rough timing of the sound card you can enter this
> at a parameter to the sweep measurement and use there a shorter repetive
> sync signal?

The timing of sound cards (and software) regarding the loopback latency 
from playback to recording is not reproducible. Every time you open the 
sound device the value is quite different. For this reason it is 
necessary to do the sync every time the measurement starts.
Once the sound device operates continuously, the timing is very reliable 
because the ADC and DAC component are controlled by the same crystal 
oscillator. I have measured delays in the order of 10ns this way with an 
ordinary AC97 48kHz on board device.

> Disclaimer: I have no experience how deterministic the delay of a sound
> card is.

It's not only the sound card. There are some software components and 
FIFOs in the processing pipeline. Depending on the system load and I/O 
latencies they might initialize delayed.


Marcel

Am 24.02.2018 um 20:16 schrieb Marcel Mueller:
> Hi,
> 
> I have some (quite old) network analyzer software source code which 
> creates amazingly accurate results with PC sound devices. Basically it 
> outputs some reference to line out while sampling its own output at the 
> right channel and the two port response at the left channel.
> 
> When using (cyclic) noise patterns as reference everything is fine 
> because any latency is cancelled by the sampled reference at the right 
> channel.
> But for measurements in sweep mode (frequency scan) I need to 
> synchronize the ADC input to the sampled reference signal to keep 
> reference and analysis correctly aligned. Once I have synchronized I 
> simply count the samples to advance to the next frequency bin.
> 
> PC sound devices insert some unknown latency to the signal path. Since 
> buffer overruns or underruns are unacceptable the buffers are rather 
> large and the latency is up to some seconds.
> 
> The idea is to precede the reference signal with some sync pattern that 
> is recognized by the analysis part. Once it is in sync all samples until 
> the end of the reference are discarded and the main measurement starts.
> I.e.
> DAC:sync_sync_sync_sync_sync_|Frequency_1_Frequency_1|Frequency_2_Frequency_2|... 
> 
> ADC:...eat_samples_up_to_here|setup_delay|_Measure_1_|setup_delay|_Measure_2_|... 
> 
> 
> But there are some problems:
> 1. a sync window of several seconds creates unreasonable large FFT sizes 
> for cross correlation, especially when operating at high sampling rates 
> like 192 kHz. I would like to keep the FFT size in the order of 64k.
> 2. Even if I manage the large FFT there would always be considerable 
> noise in the cross correlation when the window sampled for 
> synchronization does not fully capture the sync pattern.
> 3. If I choose a smaller FFT size with a repeated pattern I get almost 
> no noise. But because of the aliasing I do not know when the last cycle 
> of the sync pattern has been played.
> 
> Is it possible to add some number to the sync pattern that can be 
> decoded easily without adding too much noise to the cross correlation 
> result? A few bits should be sufficient.
> The difficult part is that everything needs to be wide band, because 
> there is an unknown transfer function between DAC output and ADC input 
> that could eat up some frequencies almost completely.
> 
> How to identify the last sync frame reliably?
> 
> 
> Marcel

I wonder if you can separate the delay measurement from the sweep 
measurement?
Think of it as some kind of calibration step where the rough timing of 
the sound card is estimated. You would need a sync signal with good 
auto-correlation properties. You than can even do the processing offline 
if all you are doing is recording some seconds from the sound card where 
you expect the sync signal.
If you than have the rough timing of the sound card you can enter this 
at a parameter to the sweep measurement and use there a shorter repetive 
sync signal?
I am not sure if this is feasible with your setup but maybe it is worth 
a try...
Disclaimer: I have no experience how deterministic the delay of a sound 
card is.

Greetz,

Sebastian

Hi,

I have some (quite old) network analyzer software source code which 
creates amazingly accurate results with PC sound devices. Basically it 
outputs some reference to line out while sampling its own output at the 
right channel and the two port response at the left channel.

When using (cyclic) noise patterns as reference everything is fine 
because any latency is cancelled by the sampled reference at the right 
channel.
But for measurements in sweep mode (frequency scan) I need to 
synchronize the ADC input to the sampled reference signal to keep 
reference and analysis correctly aligned. Once I have synchronized I 
simply count the samples to advance to the next frequency bin.

PC sound devices insert some unknown latency to the signal path. Since 
buffer overruns or underruns are unacceptable the buffers are rather 
large and the latency is up to some seconds.

The idea is to precede the reference signal with some sync pattern that 
is recognized by the analysis part. Once it is in sync all samples until 
the end of the reference are discarded and the main measurement starts.
I.e.
DAC:sync_sync_sync_sync_sync_|Frequency_1_Frequency_1|Frequency_2_Frequency_2|...
ADC:...eat_samples_up_to_here|setup_delay|_Measure_1_|setup_delay|_Measure_2_|...

But there are some problems:
1. a sync window of several seconds creates unreasonable large FFT sizes 
for cross correlation, especially when operating at high sampling rates 
like 192 kHz. I would like to keep the FFT size in the order of 64k.
2. Even if I manage the large FFT there would always be considerable 
noise in the cross correlation when the window sampled for 
synchronization does not fully capture the sync pattern.
3. If I choose a smaller FFT size with a repeated pattern I get almost 
no noise. But because of the aliasing I do not know when the last cycle 
of the sync pattern has been played.

Is it possible to add some number to the sync pattern that can be 
decoded easily without adding too much noise to the cross correlation 
result? A few bits should be sufficient.
The difficult part is that everything needs to be wide band, because 
there is an unknown transfer function between DAC output and ADC input 
that could eat up some frequencies almost completely.

How to identify the last sync frame reliably?


Marcel