I/O ping mysteries

I've recently plumbed in a Comp-3A (golden age) mono compressor - my first step out of the box  - before I start committng to use it in projects I just want to confirm that I understand what '+1' means when pinging.  Does it mean I need to adjust the recording delay in preferences by subtracting a sample - adding a sample - or does logic recognise the reported delay and automatically adjust internally?

Secondly, if I do need to adjust the recording delay and I happen to be using a second /i/o - external compressor on another track or bus that reports a different amount of latency and adjust the recording delay accordingly for that , would that not in turn improperly offset the first track that only requires an offset of 1?  Im assuming that recording delay adjustments as I'm describing are required when using external effects during a real time bounce.

Many thanks 

M7

It means that your audio interface's driver is under-reporting it's latency by 1 sample. Ping for my RME Fireface UCX reports +1 too, confirmed by RME. You then have to invert that number (i.e. convert +1 to -1) and manually enter -1 samples as your Recording Delay in Preferences > Audio > Devices.

You can only specify one Recording Delay (I think we should be allowed to specify more than one Recording Delay btw), so it really only works for outboard that has zero processing latency, or for basic recording of non-software monitored sound sources. So a digital EQ connected to an I/O plugin would be recorded late, unless you temporarily decrease the Recording Delay from your default of -1 samples.

See my post below for the various ways to overcome this when recording the outboard-processed signal coming back into the I/O plugin. There's also a quick summary a couple of posts below this post:

Best way to record I/O plugin

Hope this helps.

my RME Fireface UCX reports +1 too

Do you get the same mismatch when running at double SR?

my RME Fireface UCX reports +1 too

Do you get the same mismatch when running at double SR?

I haven't tried yet.

Thank you Red Baron, I've read your comprehensive post - I will need to digest it for awhile to get my head around it. One basic question that occurs to me is  - what  if you want to strap a stereo compressor across the mix buss and you also instantiate  latency inducing plug ins in its chain?  Would I then need to send the output to yet another bus before bouncing? ( you probably answer this in your post) Also, in general, are there plug in latency compensation settings/low latency mode issues to be aware of?

my RME Fireface UCX reports +1 too

Do you get the same mismatch when running at double SR?

Yes - its the same

my RME Fireface UCX reports +1 too

Do you get the same mismatch when running at double SR?

I should have said +1 samples at 48k.

As, for Double Speed (DS) and other samples rates, here's some Ping results for the USB driver that I did a couple of years ago; double checked with (more reliable) manual loopback recordings:

  44.1k = +1

  48.0k = +1

  88.2k =   0

  96.0k =   0

176.4k = +1

192.0k = +1

And for the Firewire driver:

  44.1k =  0

  48.0k =  0

  88.2k =  0

  96.0k =  0

176.4k = -2

192.0k = -2

 

... what  if you want to strap a stereo compressor across the mix buss and you also instantiate latency inducing plug ins in its chain?

By 'chain', do you mean latency inducing plugins on the same output channel strip ('mix buss')? Or do you mean latency inducing plugins on an Aux, before the audio reaches the output channel strip?

Either way, recording the signal returning to I/O plugins on output channel strips is very restrictive, and will only work sample accurately if the outboard itself is zero latency, and other strict restrictions are adhered to (see 'Recording an I/O Plugin from an Output' from this post).

 I suggest you create an 'output Aux' that's simply an aux that acts as a 'middle-man' just before the output channel strip. Instead of routing tracks and aux-sends straight to an output, I route them ALL through the 'output Aux' first, which is the only channel strip routed directly to the output channel strip. All other tracks/auxes go through that intermediary aux first. I never route audio direct to an output channel strip on my system, I have an 'output Aux' for each of my output pairs, and put latency inducing plugins on the 'output Aux' instead of the output channel strip. I think this is pretty much answers your question below:

 

Would I then need to send the output to yet another bus before bouncing?

Yes, as I said above, use an intermediary aux and put the I/O plugin on there and only route the intermediary aux to the 'mix buss'. I/O plugins on Aux channel strips are just easier to work with.

However, you'll be fine recording the return signal from an I/O plugin on an output channel strip so long as the outboard is fully analogue with zero latency (i.e. the I/O plugin's latency is exactly the same as your usual roundtrip latency). But you also can't have any latency inducing plugins before the output channel strip's I/O plugin, either on an aux (send) or inserted onto the output channel strip before the I/O plugin (but you can insert latency inducing plugins after the output channel strip's I/O plugin, and latency inducing plugins on audio or instrument tracks are OK). Basically, the output channel strip's I/O plugin must be the first latency inducing plugin after your audio/instrument tracks.

^ But on the whole, it's just easier to record an I/O plugin's return signal if you put it on an aux. See 'Recording an I/O Plugin from an Aux - Method 2', again from this post. 

am I doing something wrong by just phase aligning after the fact?

It's just a slower way to work, and potentially not sample accurate unless you have clearly defined transients to help you line things up (unless you're using a tool to align phase?). If you configure Logic correctly, recording latency compensation is sample accurate so long as everything you recorded was in sync with Logic's *metronome* in your speakers during recording.

For me, moving audio (regions) around after recording kills my inspiration. I prefer to record and move on immediately to the next task.

Otherwise, whatever works for you. I don't like to tell people how to work. I generally just talk about latency configuration and other technical issues.

Hi Guys! Longtime lurker here and really enjoy the forum. Now it's time to participate.

RedBaron, are you sure that you have to adjust the recording the delay? I think that is what the Latency Offset in the I/O Plug-In is for. At least this is how it works for me.

For example I have an DP4+ and this reports +47 sample and then I have an MPX and this one reports +125 samples. I leave the recording delay as it is at 0 and work with those settings from the I/O Plug-In and everything works.

For example I did what Eric Cardenas suggested and measured the input and output from interface output to input and got -17 samples. Should I set the recording delay now to +17 or leave it at 0?

Maybe somebody could shed some more light on the Issue. 

Thanks so much!

SF

Yes, you should set the recording delay preference to +17 in your case if that's mismatch between the reported round trip latency and the actual round trip latency. This will help Logic record "in time" when using software monitoring.

The Latency offset fader is there to offset the round trip latency of that specific In/Out chain. Depending on the hardware you use it may be greater than the monitored round trip latency.

Eric's pretty much said it all.

The Latency Offset is for output alignment using the PDC system.

The Recording Delay is for input/recording alignment.

Thanks Eric, thanks RedBaron! Now after dealing with the whole issue everything is much clearer.

As RedBaron suggested it would be great to have more recording delays. I work with two Motu AVB and a Ferrofish ADDA over ADAT and all of them have different offset values, ranging from -17 to +31. The Motu 16A which has +31, is used to route effects only so and now that I know and tested that all the effects sit tight when on a bus, I'm good.

But I'm recording from the Motu 1248, which reported an offset of -17 and also from the Ferrofish, with an offset of +5. Since I'm not recording too many channels with the 1248, I always nudge them a bit into place. 

How are you dealing with this?

I would use the most latent roundtrip as you Recording delay to compensate for that.

Then create Input objects on the MIDI Environment and insert Sample Delays with the difference to compensate for the less latent ones.