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?
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 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.
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).
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
@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
I really appreciate your comments on this topic. Thanks!!
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.
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.
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.
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?
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.
