Delay with busses

[daeron80]

Originally Posted by Syncrecy

If not there goes all my beautiful outboard gear!!!

Not at all. This issue is about live recorded audio being placed later than it should be.

[Chris Watkins]

This is precisely why I was making destinction between realtime-routing phase issues and the setback. Because it would concern people using outboard gear and all other functions.

So, since it now seems people say they can hear this delay as well that would explain why the recorded audio is also not in place.
It may also explain why I don't have this issue, because my audio is not delayed.

I also proposed that one inverts the signals using a NULL and viewing the difference with a master fader like one normally would.
Because this way there is no question as to how much zipper or phase.
But, if you notice by picture, there is 0 signal in the master fader when the signals are NULLED and I got 2x signal without them (although I had use my ears to decide I didn't hear phaseness + signal increase, where with the null, I can turn it up all the way and hear absolutely nothing. I had that run for hours incase it was a stream offset problem brought on by load, which has been seen in other native daws. But, I got nothing.

So, to clarify now, those that see the problem also have real-time audio out of sync as well? is this from an external source?
(After several pages of avoidance, I'm not sure anybody directly answered whether or not their realtime was in or out of sync, just a bunch of complaining that it was irrelevant. However, now I see, (and I didn't re-read the entire thread) that those with recorded audio offset also have realtime-audio issues? And, based on the message from AVID and the dead-end statements, those with the offset, did you try the NULL test (you must add a plug to invert phase, no way otherwise) and although a master fader isn't required this way you can see that their is no audio and it does add one fader, which *shouldn't* make a difference, but since dce seems to be based on the delays to the out, it's possible a computation doesn't happen without it. (I did not see any master faders in the other screenshots..)

[Chris Watkins]

Originally Posted by jasonmiller0607

I think there may have been some confusion in some earlier posts about hearing a delay. Since I never record both signals (direct to audio track, and through and aux track) simultaneously other than to test, I never "hear" a delay. Because all the tracks I monitor have gone through busses and are all delayed equally. 213 samples @ 44.1 kHz would be nearly impossible to hear anyway. BUT... that still doesn't make it okay!

If I were to monitor both signals at the same time, I would obviously hear a delay. Really, anything more than a sample or two will sound awfully "phasey".

So, obviously you just wanted to argue and never bothered to test it.
If you look at my screenshot, I get 0 delay and 100% NULL realtime.
Again, if you reference my last post and do the routing scheme in my picture,
if you still have a delay, something is obviously different than me.
But, NO, you shouldn't NOT hear a delay between the aux routed and direct routed track and I don't 100% of the time. To make sure, the best way is to
add say eq1, phase flip one of the channels and add a master fader to make the test the same and you should get NO audio. This way nothing is relying on ears of buffersize, mathematically it should 180 degrees cancel and accross the board nothing should be heard.
If you get a realtime-delay then that's a problem in inself and the audio is getting placed correctly. If you get a NULL and the audio is not placed correctly that's something different.. But again, mine line up, so..
I figured you guys would have at least tried these things; even though there is a output buss, the instance of a master fader or lack there of might make a difference, but at this point that's the only difference I see.
Course, it's impossible to know without the test, but perhaps it was just lack of response and doing the tests that made me think you had in phase realtime audio and offset recorded audio.. But if you have both..

[Chris Watkins]

Also, FWIW:
If I remove in the I/O window the "buss" attached to my default I/O
then cmp delay goes away on the aux.
This makes no realtime difference in the NULLING, but since I'm
not having the issue even though it doesn't do anything for me,
it might nullify the issue for those that do. In anycase, I had
thought of suggesting it before, but nobody's suggested it to
maybe for those that see a issue it changes it? at any rate it
changes the display.

[jasonmiller0607]

Chris...

I've done the null test. During RECORD the signals do null. You're right, that's interesting. But, it doesn't fix the problem or prove there isn't a problem. ONce the two signals are recorded into Pro Tools, they are out of time on playback. The track that was routed through the AUX is still delayed. The problem is still there.

So, all the null seems to prove that during RECORD a musician should not hear any additional delay caused by the AUX track. However, once the audio is recorded it is still delayed. That's what this whole conversation is about.

Are you saying it's not a problem that the audio is delayed?

Are you saying you have a solution to prevent it from delaying the audio?

[dankin]

Here's how I tested it. I created 2 tracks, 1 aux input and a Master fader. Track 1 and the aux input were both assigned to input 1. Track 2 input was assigned to a bus which was the output of the aux input. I put a trim plug on Track 1 and Track 2 so i could check phase while recording. Everything IS totally phase accurate while recording. However when I hit stop track 2 is 392 samples late. Doesn't matter whether delay compensation is on or off. Doesn't matter whether there is a master fader or not. Doesn't matter if there is any plugins or not the result is the same.

[jasonmiller0607]

Preeeeeeecisely.

[Chris Watkins]

Thanks dankin.
You've proved there is no realtime delay and jason agree's.
Nice to see he finally does.
and you're right, I went through the master fader and had no differences.
Went on to I/O and trashing settings and so forth.

[Chris Watkins]

Originally Posted by jasonmiller0607

Chris...

I've done the null test. During RECORD the signals do null. You're right, that's interesting. But, it doesn't fix the problem or prove there isn't a problem. ONce the two signals are recorded into Pro Tools, they are out of time on playback. The track that was routed through the AUX is still delayed. The problem is still there.

So, all the null seems to prove that during RECORD a musician should not hear any additional delay caused by the AUX track. However, once the audio is recorded it is still delayed. That's what this whole conversation is about.

Are you saying it's not a problem that the audio is delayed?

Are you saying you have a solution to prevent it from delaying the audio?

The conversation only turned to the fact that it's only recorded audio that is
offset AFTER I proved the NULL, so to insinuate I am arguring about something completely different is just silly.
You're title and original description pretty much said that a delay in routing
was caused by this, I simply said no.
I then proved it and we moved on to it's ONLY the recording.

It has now been further defined to see that audio is offset.

Now, I do have interesting news. It kind of answers you're second question.
**
After mucking with I/O, doing pref resets and so forth..

I now have the problem. I can't seem to get it to go away and it WAS working..

So, now I'm off to see if it's the new feature of copy session settings sessions from other sessions and because I frequently have loaded HD sessions and used their defaults.

Because, it did work and now I can actually re-create you're problem.
So, I had a solution, just didn't know what it was, because whatever it was, I
always had it and by doing massive resets and defaults, I now have the problem.
So, go figure, closer to finding it now that I've infected myself.
But in my pic you can see they are not offset, I also watched it for almost
two days be in sync.
I'd do something insane like reboot, but I've got 24 days uptime, so obviously it's not something like that.

Again, it's important to know who else does not see the issue.
Running it with the realtime NULL in place is just assuring that the
engine is not off dce wise.

Also note:**
When I change the comped values on the channels, I kind of expected the
realtime audio to change and do zipper slips.. This is not happening now,
changing the comp is not delaying the realtime audio.
Because I wasn't expecting it when it happened it's hard for me to
reconfirm precisely, but it does not seem now that I have this offset
issue that I can modify the DCE values and have them make any difference.
(And correct me if I'm wrong, Avid, or someone with TDM HD, (NOT Native HD), if you screw with the-/+ comp it offsets you're realtime audio??)

[jasonmiller0607]

I am saying this with the biggest eyeroll I can possibly make. The point was never what it did in realtime. I don't know about y'all, but I mix records AFTER the recording stops. So, for me, the playback is the important part.

My problem and my original post had nothing to do with realtime playback.

@Chris, yes, it's interesting that it ISN'T delayed in realtime... but right now it's not much more than just interesting.

Also, I'm glad you're finally having this problem yourself. Welcome to that party.