I enjoyed this. Its funny, some well known engineers still use those alesis verb units.

One concern i always have with hardware effects is if the delay compensation is working to sample accuracy. Just curious if you've ever tested this in Samp.

kmetal, post: 465453, member: 37533 wrote: ...delay compensation is working to sample accuracy.

I'm not sure what you mean by this. Internal effects have inherent latency that can be addressed internally. Outboard effects may have some latency, but the software has no way of detecting it, and it's likely to be very small since they're dedicated hardware units that don't have to share processing with anything else.

bouldersound, post: 465454, member: 38959 wrote: I'm not sure what you mean by this. Internal effects have inherent latency that can be addressed internally. Outboard effects may have some latency, but the software has no way of detecting it, and it's likely to be very small since they're dedicated hardware units that don't have to share processing with anything else.

Protools and logic have delay compensation for outboard hardware inserts. Its compensation for the ADDA conversion involved with using the external effect. If the effect has its own lantency like a digital effect connected via analog, im not sure it can compensate for this.

Take an analog eq for example. Your going DA from interface, thru the eq, and back into the AD of the interface. If the interface has a 4ms RTL (round trip latency) your new eq'd signal from the hardware would not line up with the source track. This would cause phase cancellations. The delay compensation is supposed to compensate for the RTL from the conversion, so things line up.

I don't believe it can dectect a digital ob units internal latency, so i "presume" you would have to manually set an offset for it, or connect digital peices digitally.

I brought this up because a podcast with chuck zwiki, (NIN, Rembrants) mentioned this as a big issue he had in logic, since he's hybrid and uses racks of outboard. He worked with logic to make a pluggin to fix this.

As an aside he also mentioned there was a time where he would get different i/o latency via usb and fw interfaces, when he restarted his machine. This further complicated his mixing and tracking. He solved that by using a pcie based motu setup. So im now a bit paranoid that usb interfaces may still exhibit this behaviour upon restarting.

kmetal, post: 465455, member: 37533 wrote: Protools and logic have delay compensation for outboard hardware inserts. Its compensation for the ADDA conversion involved with using the external effect.

Why would that be different from the ADDA conversion of overdubbing a live source over an existing track? If an overdub is recorded without an offset, then an effect should be captured without an offset (other than the outboard's own internal latency).

bouldersound, post: 465456, member: 38959 wrote: Why would that be different from the ADDA conversion of overdubbing a live source over an existing track? If an overdub is recorded without an offset, then an effect should be captured without an offset (other than the outboard's own internal latency).

Right if the delay compensation is working accurately, it will line up without offset (manual offset would be for compensating the hardwares latency if it had any).

The problem is delay compensation doesn't always work accurately.

There has to be compensation to line up the existing audio, with the re-converted audio from the hardware box. Otherwise the newly recorded sound would be late, subject to the interface latency.

If you tracked a sound coming from your speakers with a mic, to a new track, they would not line up sample accurately. If you subtract the ms of time from the sound actually moving between mic and speaker, you've got the time it takes to DAAD convert.

Before delay compensation you were forced to use hardware monitoring so you were singing/playing in time when overdubbing. Or you used dsp in the interface.

This was a big deal for PT users when PT introduced hardware inserts, they didn't always have it. A hardware insert, is different in PT than just a regular aux. Tho PT delay compensation is still iffy according to what ive heard from even bigger name engineers.

I don't claim to have a deep understanding of the topic, but i know its something that can be an issue.

My point is, if an overdub lines up correctly then a hardware insert should be the same. To the DAW they're essentially the same thing.

It would be interesting to run loopback tests on some of our systems.

Hum interesting guys !
I haven't thought of checking this.
I guess if something wrong had gone by, I would have heard phasing issues which is not the case here.

This latency is always an issue when re-amping something in PT. Sure the latency can be controlled through the use of the delay compensation, but it does not always work like you think it should especially in round trips from a digitally captured source out to analog of some sort and then back as a newly minted digital capture. It's funny sometimes....You get the real time monitoring through delay compensation down to a usable number when capturing the track and then when you listen back it's on another planet timewise. And this is after making sure your start/stop numbers are correct. Another interesting aspect of digital recording. I imagine that the scenario that Chuck Zwiki is dealing with is importing lots of sources from different media into a session.

And yeah...I get that you'd think that once the source track has been digitally captured and converted that anything you might do to it in the future would have no effect in the delay world.....but that's not always true.

One thing I have found....when you try to reamp a track that has been edited with the elastic audio in PT, all bets are off. Something in the elastic audio part wants to refer back to it's original position in the track no matter what your compensation is at when you try manipulating it through a round-trip.

bouldersound, post: 465458, member: 38959 wrote: My point is, if an overdub lines up correctly then a hardware insert should be the same. To the DAW they're essentially the same thing.

It would be interesting to run loopback tests on some of our systems.

I agree it would be interesting to do a loopback tests.

I think the difference in an overdub is the overdub just needs to be sync'd with the existing tracks, but a loopback has to be in sync with itself. So on an overdub you can delay the tracks enough to compensate for the AD conversion, and everything hits the daw at the same time.

With a loop back the existing audio has to line up with itself, after the AD conversion. This means you have to delay the existing tracks twice as long, to compensate for the DA and AD. So the loopback has time to AD convert, and line back up itself on another track.

One is just syncing input, the other is syncing an output/input combo. In an overdub the DA latency isnt time sensitive to the session timeline. no matter how long the DA takes, as long as the AD signal meets it there is no issue. With the loopback, the DA signal already has a point in time in the session, its got to meet up with itself after the AD, as opposed to meeting up with a fresh signal, that didn't experience a DA conversion before hitting the AD on the way in. An overdub just compensates for the latent input signal, the loop has to compensate for the latent output, and input. In an overdub your only printing an input signal.

That's how i think about it, tho im not sure its completely correct.

Since a person playing an overdubbed part is hearing the playback, the resulting audio timing on the record side of the DAW is a consequence of output latency plus input latency, just like an effects loop.

bouldersound, post: 465485, member: 38959 wrote: Since a person playing an overdubbed part is hearing the playback, the resulting audio timing on the record side of the DAW is a consequence of output latency plus input latency, just like an effects loop.

Your not re-recording the output signal. So you just delay the output to sync with input on an overdub.

With an effects loop it can't be that simple, you can't just delay the output to line up. The output is the input.

Think about it. How could a track in a session line up with itself, after 4ms of input latency? It would always be 4ms late.

In an overdub how much delay used by the delay comp doesnt matter, as long as the input is in time. In a loop it has sync with itself. There's 2x the conversion time in a loop because its the same track.

Overdubs are parallel conversions, a loop is conversions in series.

kmetal, post: 465486, member: 37533 wrote: Your not re-recording the output signal. So you just delay the output to sync with input on an overdub.

Except the performer is playing to the output. The performer is timing their performance to the output, so output latency gets incorporated into the performance, then input latency is added to that.

bouldersound, post: 465488, member: 38959 wrote: Except the performer is playing to the output. The performer is timing their performance to the output, so output latency gets incorporated into the performance, then input latency is added to that.

Right. So the output latency could be 15 sec, and not matter because the performer is responding to when they hear it.

On an effect send if there was a 15 sec output latency then the unit would receive the singnal 15 seconds later than it actually is on the timeline, which is important on the effect send case, because the send needs to line up with the original signal at the same point in the timeline. In an overdub your performing to the delayed signal. You just have to line up the incoming AD signal. In the send the device is "performing" to the non-delayed signal. The daw has to line up both the DA latency and AD latency to the original signal the daw is sending from. Its got to compensate for both. An overdub just has to compensate for AD latency. An overdub is relative to the delayed DA signal, the send effect is relative to the absolute signal from the send track.

The send track has a fixed point on the timeline, so any latency incurred is relative to that fixed point in time. With the overdub it doesn't exist until after the DA, so it only needs to be in time relative to the DA delayed signal.

The "stopwatch" starts counting when the listener recieves the signal for an overdub. It starts when the daw sends the signal for an effect send.

kmetal, post: 465489, member: 37533 wrote: Right. So the output latency could be 15 sec, and not matter because the performer is responding to when they hear it.

But it would matter. A hardware device is also responding when it "hears" the signal just like a human. In both cases, human and hardware, they don't start processing the output signal until they receive it. On a technical level, there's literally no difference.

When I get time, I'll make some tests..

IF the software is intelligent enough, once you hit stop after recording round trip, it aligns the audio data to compensate for the possible delay...
Or AD and DA converter might be so fast now that it doesn't mather.. but I guess we are doubting it.. ;)

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.

bouldersound, post: 465490, member: 38959 wrote: But it would matter. A hardware device is also responding when it "hears" the signal just like a human. In both cases, human and hardware, they don't start processing the output signal until they receive it. On a technical level, there's literally no difference.

When the hardware hears it is the same as the human would, yes. But the effect needs to line itself up with itself, the overdub need only line itself up with what its hearing. An overdub doesn't line itself up with its own pre-conversion signal, it doesn't exist yet.

If the effect hears the signal 15 sec late, even if the AD latency is compensated for, its still printing the new signal 15sec later than the original is in the session. The effect send needs to travel "back in time", the live overdub need only stay in time with the post DA signal.

The difference is what in the session the new signal needs to align to. That's where the compensation is different. The effect send needs to compensate a round trip, to line the signal back up to itself. The overdub just needs to compensate for the AD conversion.

If there wasn't a difference, why would there be a dedicated "hardware insert" function? You would just use a regular bus, and the recording delay compensation would be enough. One is a one way trip, the insert is a roundtrip. They can't be the same, its two different processes.

pcrecord, post: 465492, member: 46460 wrote: When I get time, I'll make some tests..

IF the software is intelligent enough, once you hit stop after recording round trip, it aligns the audio data to compensate for the possible delay...
Or AD and DA converter might be so fast now that it doesn't mather.. but I guess we are doubting it.. ;)

The software is supposed to be intelligent enough to sync it in the session to sample accuracy. Logic and PT, aren't always performing the task properly. Its a known issue.

Also interesting is the latency occured due to a digital outboard vs analog, due to the additional conversion in the box itself. I wonder if that latency can be compensated for by word clock, or if you have to manually set an offset. Im not sure there are any issues of this nature if the effect was connected digitally. I set my cousins apollo and eleven rack up via spdif for his re-amping. It avoids conversion and i presume the latency issues.

audiokid, post: 465493, member: 1 wrote: 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.

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

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.

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.

Boswell, post: 465503, member: 29034 wrote: 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..

pcrecord, post: 465506, member: 46460 wrote: 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.

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.

Boswell, post: 465503, member: 29034 wrote:

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?

kmetal, post: 465510, member: 37533 wrote: 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.

bouldersound, post: 465511, member: 38959 wrote: 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.

kmetal, post: 465510, member: 37533 wrote:
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!

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 ?

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.

Boswell, post: 465513, member: 29034 wrote: 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.

pcrecord, post: 465515, member: 46460 wrote: 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.

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..

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.

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!! ;)

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

kmetal, post: 465573, member: 37533 wrote: Hey Marco i meant to ask, what sample rate were you using for these tests?

I'm recording everything in 24bit/96khz

kmetal, post: 465572, member: 37533 wrote: 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 !! ;)

pcrecord, post: 465576, member: 46460 wrote: 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.

bouldersound, post: 465581, member: 38959 wrote: 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?

kmetal, post: 465603, member: 37533 wrote: 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.