Mixing with external gear with Samplitude Pro X5

[kmetal]

I did these test years back using many world class converters. When mixing with outboard, I eventually moved towards two DAWs and never looked back. I learned a great deal from it. I avoided round trip processing and talked about this. Long story... Once ITB, stay ITB.

I remember in DP7, we would have to add a "dummy" effect on parallel channels because otherwise the delay compensation wouldn't work properly, and you'd get phasing.

I love itb, but i realize more and more how little i know about whats going on under the hood. Lol one sample library loads to ram, the other streams off the ssd, one loads across multiple cores, the other single core only.

I think my naive "throw paint at the canvass" methods of yesteryear, exposed many flaws in my knowledge and the programs, that contributed to me chasing my tail.

 

[pcrecord]

You can have different results depending on your equipments and softwares, but here's my tests on delay compensation :

 

[Boswell]

Nicely done, Marco!

Samplitude will time-compensate the primary connected interface so that a loop-back from one of its analogue outputs to an analogue input will time-align to the nearest sample, as you demonstrated. As far as I am aware, the same delay value is used as the default for all channels on the device.

What it cannot know is whether you have some channels fed via external converters connected via ADAT (or S/PDIF), when the round-trip timing will be different. You can manually adjust the default delay compensation for individual tracks that are input (or output) via digital I/O so that they align to the nearest sample, taking into account the delays through external hardware.

I would be interested to know what the result would be with your equipment at the default delay times if you were to split the click output to feed both a native UFX analogue input and your ISA pre-amp/converter via ADAT. How much time do you have to add for the ISA - ADAT route?

However, the whole concept of simple round-trip compensation is flawed by not distinguishing between how much of the round-trip time is due to output delays and how much to input delays. This matters when you are overdubbing, for example, when you break the loop in the middle by supplying the output to headphones and bring the input back through a separate microphone channel, which may well be connected via ADAT or other different hardware.

One of the little jobs that I often do when I get (buy, hire or borrow) a new piece of gear is to measure and document both the input and output delays, and add the values to a file I keep. If I then have to use that gear patched in via a non-direct route, I get my calculator out and add up the delays in order to set the compensation in the replay channels.

 

[pcrecord]

I do not have the Adat card for the ISA.. They all are plugged to the line ins of the RME.. But the 4-710 has preamps and ADAT. I went to a line in in the video but I can try the preamp as well,.
Also I can try to go UFX ISA UFX in analog.

One of the little jobs that I often do when I get (buy, hire or borrow) a new piece of gear is to measure and document both the input and output delays, and add the values to a file I keep. If I then have to use that gear patched in via a non-direct route, I get my calculator out and add up the delays in order to set the compensation in the replay channels.

That's very clever..

 

[Boswell]

I do not have the Adat card for the ISA.. They all are plugged to the line ins of the RME.. But the 4-710 has preamps and ADAT. I went to a line in in the video but I can try the preamp as well,.
Also I can try to go UFX ISA UFX in analog.

Sorry, I forgot your ISA does not have the converters. I must have been thinking of the 4-710. For ISA in my post read UA 4-710.

There won't be any time difference (at this level) between the mic inputs and the line inputs.

 

[kmetal]

Nice work Marco, a very interesting test. The only other test i would have liked to see was if there were pluggins on the track being recorded, ie if you were monitoring with realtime effects, does the delay compensation work as precisely as without them on the live input.

Ive had some time alignment issues when printing from drumagog internally, where some of the hits didn't line up when printing it.

Glad to see Samplitude delay compensation works, although the one sample difference bugs me, lol.

Its also makes me wonder if what we are recording is sample accurate, are we capturing the exact performance we laid down?

I guess i need to include a click for reference whenever i re-amp now.

What it cannot know is whether you have some channels fed via external converters connected via ADAT (or S/PDIF), when the round-trip timing will be different. You can manually adjust the default delay compensation for individual tracks that are input (or output) via digital I/O so that they align to the nearest sample, taking into account the delays through external hardware.

If the unit was sent and returned via adat/or spdif should it be in perfect sync since there is no conversion taking place? (Barring any lantency, if any from the units dsp)

Or is there inherent latency built into the adat/spdif no matter what?

 

[bouldersound]

If the unit was sent and returned via adat/or spdif should it be in perfect sync since there is no conversion taking place? (Barring any lantency, if any from the units dsp)

Or is there inherent latency built into the adat/spdif no matter what?

There's still some buffering involved. But the good thing is that (I'm guessing) it would probably be an exact number of whole samples off rather than fractions of a sample you might get with converters.

 

[kmetal]

There's still some buffering involved. But the good thing is that (I'm guessing) it would probably be an exact number of whole samples off rather than fractions of a sample you might get with converters.

That makes sense since those connections can carry word clock signals.

 

[Boswell]

If the unit was sent and returned via adat/or spdif should it be in perfect sync since there is no conversion taking place? (Barring any lantency, if any from the units dsp). Or is there inherent latency built into the adat/spdif no matter what?

If measuring via a DAW, you are quantised in time to the nearest sample instant. Time does not exist between samples.

You can perform a simple check by looping both an analogue cable and a digital (S/PDIF or ADAT) cable round your interface. Send the same click to both outputs and record the inputs as well as the original click position. Both external loops may show at least one sample time delay on the original, and they may well be different. I have seen DAW/interface combinations where analogue and ADAT line up but S/PDIF was as much as 3 samples late.

You have a lot of factors going on together here. There is how much your DAW can compensate for I/O latency in the interface, how much it knows about different path times through the analogue and the two digital routes, and whether the click generator automatically puts a delay in the displayed click time to match the default round trip time. It's tricky stuff!

 

[pcrecord]

So the tests list would be :
Compare analog line out to line in VS analog line out to preamps to analog line in
Compare analog line out to line in VS analog to ADAT
Compare analog line out to analog line in VS analog line out to preamp to ADAT.
Compare direct analog to analog VS analog to SPDIF

Should I go as far as comparing transformer preamp vs tube preamp ??
Should I also compare with clean project vs complete mix ?

 

[Boswell]

I don't think there is any point in differentiating between XLR microphone inputs and TRS line inputs. At the level of these tests, all analogue routes are instantaneous, and that includes transformer inputs and outputs and valve (tube) vs solid-state. What we are checking here is the effect of A-D and D-A conversion times, serial data routing, I/O buffering and the detail of what a DAW can do to distinguish between analogue I/O and digital I/O on its connected interface.

I wouldn't do too much, Marco, as it could turn into a never-ending investigation! Maybe, for now at least, treat the Samp/UFX as a typical high-end DAW with interface and default latency compensation, and then simply try the three loopback routes: analogue, ADAT and S/PDIF. Samp/UFX is not a combination I've tested.

 

[kmetal]

If measuring via a DAW, you are quantised in time to the nearest sample instant. Time does not exist between samples.

You can perform a simple check by looping both an analogue cable and a digital (S/PDIF or ADAT) cable round your interface. Send the same click to both outputs and record the inputs as well as the original click position. Both external loops may show at least one sample time delay on the original, and they may well be different. I have seen DAW/interface combinations where analogue and ADAT line up but S/PDIF was as much as 3 samples late.

You have a lot of factors going on together here. There is how much your DAW can compensate for I/O latency in the interface, how much it knows about different path times through the analogue and the two digital routes, and whether the click generator automatically puts a delay in the displayed click time to match the default round trip time. It's tricky stuff!

It really is fascinating how much stuff is going on under the hood of a DAW.

So the tests list would be :
Compare analog line out to line in VS analog line out to preamps to analog line in
Compare analog line out to line in VS analog to ADAT
Compare analog line out to analog line in VS analog line out to preamp to ADAT.
Compare direct analog to analog VS analog to SPDIF

Should I go as far as comparing transformer preamp vs tube preamp ??
Should I also compare with clean project vs complete mix ?

Id personally like to see the all digital loop test Bos described. Id also be curious how pluggins on both live and pre recorded tracks effect things. I believe several of the Fab plugs have zero latency mode.

Either way your work is appreciated.

 

[pcrecord]

So here is a video with more tests. . . I hope it fills your curiosity.
In the end I think everybody should check for delay each time we do roundtrips, just to make sure..

 

[Boswell]

Very well done, Marco!

It's difficult to pick out meaningful combinations of round trip to test. As I mentioned in my previous post, there are two main principles to take account of:

(1) purely analogue path differences (such as line input vs mic input) will not show any difference

(2) for most DAWs, using default latency compensation will assign the "base" delay level of the connected interface to all paths through it

In addition to these, DAWs will usually make an attempt to display a click track at a screen position that allows for a round-trip. As you demonstrated, they do not always get this exactly right. If you imagine the output click displayed one clock earlier, it makes sense of all the round trips for which the default latency applies. This is a display effect and not a genuine audio time alignment difference.

I was certainly surprised by the relatively large difference you saw between the S/PDIF round trip compared with the ADAT. I can't immediately think of a mechanism for this difference, although you have to take into account that there are both input and output delays that for these digital routes may be different from the analogue defaults. In the tests that I did some time ago, the two different digital routes have come out not more than +/- 1 sample apart from one another, but that has been after adjusting the latency compensation times for digital channels vs analogue channels.

It's a great subject, and not one that I can remember that we have dealt with before at this level in RO.

 

[kmetal]

Great vid Marco! Im now thoroughly disturbed. Lol. Thanks for checking the effect of pluggins on tracks. Its important since native power has increased beyond dsp in some cases, that there are still compromises.

Its concerning me that the digital connections aren't in sync since adat/spdif expansion units are so common, especially in compact interfaces with low pre amp counts. Im questioning if you split the mic signal, if the signal would get printed in the daw in sync.

Im also wondering if we can take internal bounces for granted, ie printing vsti, or drum replacers. Or even audio track groups...

Your tests are a great example of devils in the details. And it really stresses an amount of due dilligence that can get ignored or compensated for with the wrong solution.

Maybe it wasn't the drummer who was a little late after all!!

 

[kmetal]

Hey Marco i meant to ask, what sample rate were you using for these tests?

 

[pcrecord]

Hey Marco i meant to ask, what sample rate were you using for these tests?

I'm recording everything in 24bit/96khz

Great vid Marco! Im now thoroughly disturbed. Lol. Thanks for checking the effect of pluggins on tracks. Its important since native power has increased beyond dsp in some cases, that there are still compromises.

Its concerning me that the digital connections aren't in sync since adat/spdif expansion units are so common, especially in compact interfaces with low pre amp counts. Im questioning if you split the mic signal, if the signal would get printed in the daw in sync.

Im also wondering if we can take internal bounces for granted, ie printing vsti, or drum replacers. Or even audio track groups...

Your tests are a great example of devils in the details. And it really stresses an amount of due dilligence that can get ignored or compensated for with the wrong solution.

Maybe it wasn't the drummer who was a little late after all!!

Thanks for the good words.
I too don't get why Adat and Spdif are off. They are are in sync by wordclock so why the delay ? Before the tests, I didn't think more of it and never considered it could be a problem.. Of course I'm not doing roundtrips often..
but there isn't anything better than testing by ourself to learn !!

 

[bouldersound]

I too don't get why Adat and Spdif are off. They are are in sync by wordclock so why the delay ?

Word clock just makes sure that there is no drift, that the number of samples per second is exactly the same. It doesn't control whether those samples land on the exact same spot on the DAW timeline.

 

[kmetal]

Word clock just makes sure that there is no drift, that the number of samples per second is exactly the same. It doesn't control whether those samples land on the exact same spot on the DAW timeline.

Not arguing here just trying to figure things out.

If the daw is generating the word clock, and you can set the counter to samples, wouldn't that mean the session timeline and word clock have to be sync'd?

 

[bouldersound]

Not arguing here just trying to figure things out.

If the daw is generating the word clock, and you can set the counter to samples, wouldn't that mean the session timeline and word clock have to be sync'd?

Word clock isn't timecode. All it does is say "next sample now...now...now..." without assigning any unique identity to any sample. It will prevent drift, but it doesn't prevent offset. If it were literal clocks, they could read completely different times, but that difference would remain constant.