Verify clock sync between audio interfaces

Hi,
I’ve recently bought my second audio interface, the “famous” M-Audio Delta 1010. My idea was to connect it to my other USB soundcard, a Komplete Audio 6, via the spdif in order to sync their clocks. After searching in this forum for a while I came across with, what I think, is the right set up using the ALSA backend.
Connect the spdif output of the MAudio to the spdif input of the KA6. Then, in alsamixer, I set up external clock sync in order to make the komplete audio 6 works as slave. In mudita24, choose the desired sample rate and leave the other options. That’s my “hardware” settings.

As @x42 suggested in other topics, I start ardour using ARDOUR_ALSA_EXT=“hw:4” Ardour8 and select the ALSA engine and my 1010 as the device.
Everything seems fine and I the externals aux inputs and outputs seems correct, but…
Is there a way to verify that my two soundcards are, indeed, sync?
What’s the role of adaptive resampling in this configuration?

1 Like

According to the Komplete Audio 6 manual:

SPDIF SYNC: Lights orange when External Digital Clock Sync is established; does not
light when the internal clock is used

Cheers,

Keith

Thanks for your reply Keith!! Effectively, the led lights orange so it should be working as expected. Besides that,
I was thinking about some sort of routing that allows me to verify/test that they are, indeed, in sync. Can you imagine something like this?

I doubt that is practically achievable.

I guess it might be possible to run some sort of long term test where you send a specific pattern to the audio interfaces with them looping it back, and you test whether it gets corrupted (which with out of sync interfaces it will, occasionally, have to drop or add samples to get back in sync).

But it sounds like a very difficult experiment to set up, and I wouldn’t know where to begin.

The bottom line is, the computer doesn’t have any knowledge of the sync status of the incoming streams.

Cheers,

Keith

If you can compile Ardour from source… you could uncomment the following prints

It is not realtime-safe to print, but for testing it’s fine. Check that SRC shows 1 / 1 = 1.0 . That means no adaptive resampling is performed (SRC = sample rate conversion).

1 Like

How does the system know whether to perform SRC (or not)?

Surely it’s just seeing two streams. Is it, somehow, measuring the rates?

Cheers,

Keith

It can see N streams (you can specify multiple devices semicolon separated), and yes you’re spot on:

It works by measuring the time between audio callbacks for each device, and then a DLL (delay-lock-loop, digital equivalent of a PLL) is used to calculate the the [relative] clock-speed. There is also a small dead-zone in case the value oscillates close to 1.0

1 Like

Oh, that’s interesting. Thanks for that explanation.

It seems this statement of mine wasn’t quite correct:

Cheers,

Keith

@Majik @x42 You are awesome guys!!!
It’s fantastic being able to share this high level digital audio related information. I’ll definitely give it a try, although I’ve never compile Ardour by myself :grimacing:
I really appreciate your comments on this topic. Thanks!!

1 Like

Well… I’ve kind of successfully compiled Ardour with the following prints uncommented …

I initiate a new project using ARDOUR_ALSA_EXT=“hw:4” and configure my Komplete Audio 6 as slave with alsamixer.

Then, I’ve setup a hardware loopback between my two audio interfaces SPDIFs (out to in of each other) and within Ardour send a 1kHz signal through it. I also insert an oscilloscope in the receiving tracks in order to monitor what is hapenning and seems everything allright.

Finally, this is the terminal window…

I clearly see that SRC (Sample Rate Conversion) is really close to 1 but what about “DRIFT” and “Slave capt play”. I’d really appreciate some light on this log and what’s going on.

I suppose “DRIFT” is a not correctly labelled for the case of word-clock synced devices.

Those are timestamps when the data is collected for the current cycle. This happens sequentially in each process cycle.

There will always be an offset (and jitter) when using system’s high resolution timer.

  1. both soundcards fill the hardware buffer concurrently
  2. Ardour reads the buffer from device 1
  3. Ardour reads the buffer from device 2
    … process …
  4. write data back to device 1
  5. write data back to device 2
  6. both devices play the written buffers

“DRIFT” shows the time between 2, 3, which should be constant (give or take some jitter) in your case.

1 Like

That looks like about +/- 0.1us difference. For reference AES11 and AES67 standards for synchronizing multiple pieces of equipment calls for word clock sync within 1us, so your two converters are within that by an order of magnitude.

1 Like

Thanks for the clarification…

I’ve made a little video that shows the terminal window before and after the External Sync of the slave device is set in alsamixer.

It’s interesting that before engaging it, the DRIFT doesn’t stabilize.
On the other hand, after the Ext. sync is on, the DRIFT bounces back between 1054us/50.6spl and 916us/44spl and keep rising and falling between this values.
By the way, @x42 what does spl stand for?

Hi Chris… that sounds interesting

but unfortunately I’m not shure about that 0.1us. :sob: :sob: :sob:

Very possibly I interpreted the numbers incorrectly, I was looking at the end value which varied between 155.3 and 155.1.

Those values appear to be samples; at 48kHz sample rate 155 samples is a little over 3229 us.
So the amended description is that the synchronization appears to be stable to around +/- 1 sample, or approximately +/- 21us.

Since buffers are always an integer number of samples, 0.1 sample accuracy is probably close to the limit of the rounding you get from the time API.

1 Like