latency compensation, sample accuracy, main out

Hello,

I recorded a click track.

I play this audio track in Luna.

This "audio click track" is routed to the main out.

The main out is routed directly back into "line in 1" of my Apollo 16 (cable / analog)

The click is recorded again on another audio track (Line 1 as input) in Luna.

I have an offset on both recordings.


Aren't the monitor outputs latency compensated?


PS: No plugins in the session + I/O Matrix = Default/Automatic

Thanks for the help!
Matt

cassette said:

Hello,

I recorded a click track.

I play this audio track in Luna.

This "audio click track" is routed to the main out.

The main out is routed directly back into "line in 1" of my Apollo 16 (cable / analog)

The click is recorded again on another audio track (Line 1 as input) in Luna.

I have an offset on both recordings.


Aren't the monitor outputs latency compensated?


PS: No plugins in the session + I/O Matrix = Default/Automatic

Thanks for the help!
Matt

Click to expand...

This is a bit of a "hack" for recording the click.

IOW, it's not a supported thing.

UniversalAudio said:

This is a bit of a "hack" for recording the click.

IOW, it's not a supported thing.

Click to expand...

Sorry. I think you misunderstood me.

Sorry if I didn't express myself well.

It's not about a click track.

I only used this "audio click track" to check the sample accuracy between main out and line in.

I can try to explain again:

I sent a signal from an audio track in Luna (in this case it was a click sound) out through the monitor outputs on my Apollo.

I connected the Monitor Output with the Line In of my Apollo. With a cable.

I re-recorded the signal from the line in onto a new audio track in Luna.

If I now compare both tracks, then I see that the recorded signal is too late.


I can also tell you why I took this test.

Imagine you have already recorded all the instruments, drums, guitars, etc.

These are now all in luna as raw audio tracks.
all are routed to the main out.
Rough mix with levels and panning only, no plugins.
The main out leads to the loudspeakers in the control room.

Now the singer wants to sing in the control room in front of the speakers. Without headphones.

If he uses the playback from the speakers as a guide, he will always be too late on the recording because the line in and monitor out are not sample-accurate.


It looks to me that the monitor outs on my Apollo are not latency compensated.

Is that right? Are the monitor outputs latency compensated or not?

cassette said:

Sorry. I think you misunderstood me.

Sorry if I didn't express myself well.

It's not about a click track.

I only used this "audio click track" to check the sample accuracy between main out and line in.

I can try to explain again:

I sent a signal from an audio track in Luna (in this case it was a click sound) out through the monitor outputs on my Apollo.

I connected the Monitor Output with the Line In of my Apollo. With a cable.

I re-recorded the signal from the line in onto a new audio track in Luna.

If I now compare both tracks, then I see that the recorded signal is too late.


I can also tell you why I took this test.

Imagine you have already recorded all the instruments, drums, guitars, etc.

These are now all in luna as raw audio tracks.
all are routed to the main out.
Rough mix with levels and panning only, no plugins.
The main out leads to the loudspeakers in the control room.

Now the singer wants to sing in the control room in front of the speakers. Without headphones.

If he uses the playback from the speakers as a guide, he will always be too late on the recording because the line in and monitor out are not sample-accurate.


It looks to me that the monitor outs on my Apollo are not latency compensated.

Is that right? Are the monitor outputs latency compensated or not?

Click to expand...

I understand perfectly.

Outs are delay comped to each other. If you feel you've found an issue, get a ticket open with Support and post the # here.
https://u.audio/support

UniversalAudio said:

I understand perfectly.

Outs are delay comped to each other. If you feel you've found an issue, get a ticket open with Support and post the # here.
https://u.audio/support

Click to expand...

Oh ok great.

Glad to hear that it should work.

I just wanted to rule out that I open a ticket for something that is not ment to work.

Thanks for your help!

cassette said:

Oh ok great.

Glad to hear that it should work.

I just wanted to rule out that I open a ticket for something that is not ment to work.

Thanks for your help!

Click to expand...

I didn't say that.

There might be a perfectly logical explanation for what you're seeing.

UniversalAudio said:

I didn't say that.

There might be a perfectly logical explanation for what you're seeing.

Click to expand...

I hope i get them equal. Would be important for my workflow.

And if I use a Line Out (instead of a Monitor Out) everything is perfectly sample accourate.

It is just the Monitor Outputs that are not correct comped.

cassette said:

I hope i get them equal. Would be important for my workflow.

And if I use a Line Out (instead of a Monitor Out) everything is perfectly sample accourate.

It is just the Monitor Outputs that are not correct comped.

Click to expand...

let's do some digging!

UniversalAudio said:

let's do some digging!

Click to expand...

Here in this Thread or do you mean the support ticket?

cassette said:

Here in this Thread or do you mean the support ticket?

Click to expand...

In the ticket with Support.

cassette said:

Sorry. I think you misunderstood me.

Sorry if I didn't express myself well.

It's not about a click track.

I only used this "audio click track" to check the sample accuracy between main out and line in.

I can try to explain again:

I sent a signal from an audio track in Luna (in this case it was a click sound) out through the monitor outputs on my Apollo.

I connected the Monitor Output with the Line In of my Apollo. With a cable.

I re-recorded the signal from the line in onto a new audio track in Luna.

If I now compare both tracks, then I see that the recorded signal is too late.


I can also tell you why I took this test.

Imagine you have already recorded all the instruments, drums, guitars, etc.

These are now all in luna as raw audio tracks.
all are routed to the main out.
Rough mix with levels and panning only, no plugins.
The main out leads to the loudspeakers in the control room.

Now the singer wants to sing in the control room in front of the speakers. Without headphones.

If he uses the playback from the speakers as a guide, he will always be too late on the recording because the line in and monitor out are not sample-accurate.


It looks to me that the monitor outs on my Apollo are not latency compensated.

Is that right? Are the monitor outputs latency compensated or not?

Click to expand...

Correct me if I’m wrong, but in your case I think it doesn’t matter if the monitor outs aren’t sample accurate. There will always be much greater latency/delay when audio comes from monitors to singers ears, wouldn’t there? So it really doesn’t matter if there’s a few samples more..?

Tsadar said:

Correct me if I’m wrong, but in your case I think it doesn’t matter if the monitor outs aren’t sample accurate. There will always be much greater latency/delay when audio comes from monitors to singers ears, wouldn’t there? So it really doesn’t matter if there’s a few samples more..?

Click to expand...

The example mentioned should only serve to present the problem here in the forum.

In real practice I work with an Audient 8024 analog console.

The headphone mix is ​​done on the analog level.

Now imagine all recorded tracks go out via the main out and in the live room an artist is ready for an overdub.

The main out from Luna ends up in the monitor section of the Audient 8024.
From there it is routed to the speakers in the control room and also to the headphone amp for the artist in the live room.

This means that the artist hears the main out from Luna directly in the live room. And he also hears himself directly via an aux in the channel strip of the Audient console, which is sent directly to the headphone amp before the signal even sees the computer.

It is not possible for all artists in the live room to perform to a headphone playback that does not match their performance start afterwards.
And it's also not possible that I can't properly evaluate the performance start in the control room.
That would be unprofessional.

The outs can't be compensated for recording, otherwise every track would be given additional delay by the driver—even when it shouldn't. Only AD is compensated for on the timeline.

If DA was compensated, every fresh take from an analog source would be posted late on the timeline when it doesn't need to be (or shouldn't be).

A DAW has no way to know you're round tripping a signal vs not, unless you're using hardware inserts. In the case of hardware inserts DA is compensated for because there's no signal coming in without the DA delay that it could be offset against.

This is all normal DAW behavior and is correct.

In the example above the opposite would happen—someone using headphone outs would receive extra delay when it shouldn't.

I'm not aware of DAWs that are "output aware", but if they were how would they account for digital outs feeding a different system or different converters?

All different converters have different delays. With the later UA Apollo drivers all DA converters are compensated on playback to match the delay of the DA on the monitor unit (or highest latency Apollo DA converter) so the outs are all phase coherent.

PS, I'm not sure why your line outs would line up after the round trip—they shouldn't.

However, it is accurate that both Mon and line have different delay, but this is compensated for on playback only with the later Apollo drivers.


Sent from my iPhone using Tapatalk

Matt Hepworth said:

PS, I'm not sure why your line outs would line up after the round trip—they shouldn't.

However, it is accurate that both Mon and line have different delay, but this is compensated for on playback only with the later Apollo drivers.


Sent from my iPhone using Tapatalk

Click to expand...

OK. Please let me briefly explain what I consider to be normal DAW behavior.

Just forget the practical example I mentioned for a moment. Because you’re right so far, that there are a few things that I (deliberately) didn't write down because I didn't want to complicate things too much.


Let's look at it technically next. Let's try to come to a common denominator.


A closed system of DAW and converter knows its latencies. All latencies. Those of the input converters, those of the output converters.

AVID HDX in Combo with AVID I/O does perfectly fine, and I am not surprised Luna + Apollo does also perfectly fine.

I will now describe the exact test method again. And I believe that this test method is correct. It is the right way to test sample accuracy.

And I am of the opinion that it is a matter of course for the correct function of a DAW + Converter that one comes to a sample-accurate result with this test.

Here is the test method:


TEST 1:
I sent a signal from an audio track in Luna (in this case it was a click sound)
out through the MONITOR OUTPUT L (MAIN OUT in Luna) on my Apollo 16.
I connected the MONITOR OUTPUT L with the LINE IN 1 of my Apollo 16. With a cable.
I re-recorded the signal from the LINE IN 1 onto a new audio track in Luna.
If I now compare both tracks, then I see that the recorded signal is too late.
Result: NOT SAMPLE ACCURATE

TEST 2:
I sent a signal from an audio track in Luna (in this case it was a click sound)
out through the LINE OUT 1 on my Apollo 16.
I connected the LINE OUT 1 with the LINE IN 1 of my Apollo. With a cable.
I re-recorded the signal from the LINE IN 1 onto a new audio track in Luna.
If I now compare both tracks, then I see that both waveforms are exactly equal.
Result: SAMPLE ACCURATE

TEST 3:
I sent a signal from an audio track in Luna (in this case it was a click sound)
out through the MONITOR OUTPUT L on my Apollo 16.
BUT:
Compared to test 1, I chose my other Apollo 16 as the monitoring device.
That means the main out in Luna now goes to the monitor outs of the other Apollo.
Means the physical output is the same, but it is no longer defined as MAIN OUT.
I connected the MONITOR OUTPUT L with the LINE IN 1 of my Apollo 16. With a cable.
I re-recorded the signal from the LINE IN 1 onto a new audio track in Luna.
If I now compare both tracks, then I see that both waveforms are exactly equal.
Result: SAMPLE ACCURATE



I'm not surprised that test 2 and test 3 give a sample accurate result.

And if I understood your post correctly, you wouldn't expect that. And I don't want to offend you, but I think that's wrong.

Do this test with an AVID HDX + AVID I/O and you will also find that it fits the sample perfectly.
Because that's how it has to be.

Do test 2 with an RME interface in combination with Logic or Cubase. It can happen to you that it doesn't fit exactly.
But this is not a closed system either.

That is exactly the advantage of a closed system.
AVID can do that with its software and converters and I would have been very surprised if UA hadn't been able to do this with its software and converters.


I believe that in the meantime I have found the explanation for why test 1 does not work.
As soon as you define a monitor output as a main out, it has to fulfill additional tasks. Volume control, mute, mono. I believe the sample offset here is due to the implementation of these functions.



Please, let's evaluate and discuss this for now.


We can talk about what this means for headphone mixes afterwards, because you are right, there is something to consider here and it will not be completely accurate.
But I would like to discuss that separately afterwards if you don't mind.

Happy to hear your opinion!
cheers
Matt

In my experience HDX/Carbon/HD Accel do not record back in sample accurately. This is why things like reamping always have to be manually compensated. DA is not compensated, except in the case of insterts.

In my testing over the years an output fed back to an input has NEVER aligned with the original source (that I can recall).

That includes HDX, which I no longer have, as well as TDM Accel and Carbon, which I do still have, as well as all iterations of Apollo and Antelope interfaces I've tested (all within Pro Tools) from version 8 to 2021.12.


Sent from my iPhone using Tapatalk

Matt, just thinking - what's your result when using non-corresponding I/O (out 1 to in 2)?

If you're getting sample accurate results with HDX I must be doing something wrong and AVID also isn't aware of what that may be because I have had an open ticket with them for exactly this before.

If there's a check box I'm missing I'd definitely like to know it.


Sent from my iPhone using Tapatalk

FYI, this has all been a bit of a moving target in Avid's drivers over the years.

UniversalAudio said:

FYI, this has all been a bit of a moving target in Avid's drivers over the years.

Click to expand...

Meaning you've seen it align before with some builds?


Sent from my iPhone using Tapatalk

Matt Hepworth said:

Meaning you've seen it align before with some builds?


Sent from my iPhone using Tapatalk

Click to expand...

To be honest, I have not looked at/tested stuff like this in a while, but I do remember that as things in PT got tweaked (delay comp engine, a nasty ignore errors bug that was around for a long time) results would vary.