Synchronization of sound and playhead position bug

[RedBaron]

Thanks for your reply Tom.

 

Solutions 1, 2 & 4 aren't options for me due to the way I work. Don't think? option 3 (realtime bounce) is an option either as I need to record the return from my 2 Bus chain, and bouncing is all about printing your outputs AFAIK??

 

I'll give solution 5 a go. Lots of info to take in.

 

I definitely should have said I don't have all this figured out yet. It's something I have to keep coming back to. The last time I investigated was when I realized Buses may be the answer, but didn't have time to follow it through. It just appeared that routings ending at an output were at the heart of the problem.

 

Also recording to/from Buses has thrown up another problem:

 

Recording from Bus & Count-in

 

Any ideas what's going on there??

 

Anyway, I'll get back to you on solution 5

 

Cheers,

 

: D

[CShorte]

Thanks for the detailed answers.

 

... a flaw in Logic's playback engine: MIDI timing is only going to be accurate at buffer sizes of 128 or lower. A setting of 32 will give you the most MIDI timing accuracy, 64 is a little worse, and 128 is a little worse than 64. Still, all of those setting produce acceptable MIDI timing. Anything higher and pfffffffzt!

 

On my system, I use a 256 Kb buffer for both audio and MIDI. I have not perceived any MIDI timing in-accuracy. At lower buffer settings, my AU instruments will overload my processor. Is there a way to verify or correct for the issue of MIDI timing accuracy as mentioned above? Thanks, CS.

[RedBaron]

Only partial success I'm afraid.

 

Method 5 only seems to work if you're printing the output of your stereo out without doing another round-trip through a 2 Bus recording chain (mix bus compressor etc.). It effectively behaves like a realtime bounce, with the advantage that you're recording straight onto an audio track without having to drag the audio file from the bin. The other advantage to your method is that you can use the 2 Bus Aux as a monitor controller/switcher.

 

So this IS an effective solution, providing you're printing your outputs directly.

 

Unfortunately, I need to go from my stereo outs (actually 16 channel summing, but I won't confuse the issue!) to a mix bus compressor & EQ. As soon as I do that with your procedure the resulting recording is late by 960 samples (Adaptive Limiter @ 20 ms look-ahead).

 

My only solution is to adjust by Recording Delay.

 

Any solution to my scenario?

 

: D

[nosebagger]

Hi RedBaron,

 

Glad we've got somewhere at least.

 

Without a signal flow diagram though, I'm not 100% clear on what you are doing, so sorry if I'm missing what you're getting at, but are you saying that your signal is making two roundtrip journeys when you record it? If so, that's unusual (but I'm sure you have your reasons) and problematic, because Logic will only compensate for one roundtrip.

 

In any case, instead of feeding your external processors directly from the Stereo Out (after the signal has left Logic), have you tried feeding them from an IO plugin inserted on the Stereo Out channel (or the 2Bus aux from method 5), via a spare pair of physical ins and outs (before the signal has left Logic)? As long as you remember to Ping from the IO plugin, so that Logic knows the latency of this external path, you should be good to go (with any of the realtime methods).

 

As Ski said, the idea is to use the Recording Delay parameter to sync a loopback recording that is made through your regular IO path (with no plug-ins inserted in Logic). So if your regular IO path includes, for example, external processors and/or a mixing desk, then include those in the test. If the external processors are only inserted sometimes, then don't include them.

 

Once this baseline is set, you should be able to leave the Recording Delay alone and use Logic's PDC, in combination with the IO plugin, to sync things up when adding in the external processors.

 

When you get a chance, why don't you double-check that your baseline setting for the Recording Delay preference is correct for your system and then retry the realtime methods I've outlined. If things still aren't lining up for you, post a basic, but detailed signal flow diagram for your setup (labelled rectangles and arrows would be perfect) and a clear description of what you are trying to achieve when things don't line up, and when I get a chance, I (or someone else) might be able to help figure it out some more.

 

... my head hurts now ...

 

Tom

[ski]

Why is it that we insist on trying to tackle problems that invariably induce head-hurt? (And you more so than me)?

[nosebagger]

... I guess you could say it's a sickness ...

[RedBaron]

Hi Tom,

 

I already have 5 hardware inserts, that's 10 channels. I spent about a month Pinging my whole system, at 4 sample rates and all buffer sizes to determine input, output and round-trip latency, and diagnosing problems, testing out aggregates etc. So you wanna talk about headache! I have 3 audio interfaces hanging off a Digiface, each with varying latencies.

 

I've got 16 channels going into a Little Bustard summing mixer, the outputs of the summing mixer is multed/split with a stereo pair going to a UCX for an EQ'd side chain, the other stereo pair going into an API 2500 + EQ, which then returns to inputs on my Prism, which is immediately sent out to my monitors (direct monitoring). On top of that I've got a Sync Lock and Expert Sleepers ES-4 to accommodate, and a load of MIDI and analogue gear. I'm in the middle of a complete rewire (why do I always burn my hands soldering??). Again, you wanna talk about headache!!

 

Anyway, forget all that. Simplified recording (2 Bus) routing:

 

Logic > Prism Orpheus out > API compressor > Prism Orpheus in > [Logic inputs AND Monitors]

 

Ping = +178, Recording Delay = -178

 

Now, if I want to place a hardware insert on a bus/aux, or an Adaptive Limiter on my outputs (or both), when I record via the API2500, that recording will appear late, although the relative timing is intact. So Logic has lined-up the outputs, but hasn't applied a negative delay. The only solution I've been able to find is to adjust my Recording Delay. Unorthodox and unintended function? Yes. Works? Yes. Set and forget? No.

 

So, that's 2 round-trips (< 10 ms), one via hardware insert (reverb always inserted) on bus/aux and one analogue loopback at the end via API compressor etc. The other hardware inserts are either inserted on audio/instrument channels and/or bus/aux strips on an ad hoc basis (so 3 round-trips may need to be accommodated).

 

Method 5 doesn't work for me because it doesn't make the final round-trip via the API compressor.

 

It's just an analogue back-end chain with the mix bus compressor in the middle of a loopback. I just want the audio to be recorded in the same position as the audio on the source tracks.

 

I would do a diagram, long overdue, but so much else to do at the mo.

 

Where's my aspirin??

 

: D

[RedBaron]

Bingo! Success!

 

Placing an I/O Plug-in on the "2 Bus" Aux (Method 5) to take care of my final round-trip (mix bus compressor) seems to be working.

 

I can place any number of look-ahead plug-ins before the final I/O Plug-in, insert hardware onto audio/instrument channels, and insert hardware onto Bus/Aux's and everything is automatically lined-up AND negatively delayed so that it is recorded in the correct position. So far, this appears to work with 4 round-trips + 2 Adaptive Limiters

 

Fully automatic, no need to keep re-Pinging, and I can add/remove inserts and Logic fully-compensates automatically!! Recording delay now left at -178 permanently (EDIT: Now replaced by I/O Plug-in's Latency Offset of +178). Audio input routed through buses.

 

The I/O Plug-in on the "2 Bus" Aux effectively acts as an Output & Input at the same time. I'm not actually sending or receiving to/from Outputs/Inputs directly, but once I change the I/O labels for the buses that should be a non-issue. I'm direct monitoring my 2 Bus return, but setting "2 Bus In" output to my monitors works too, albeit with added latency.

 

Very happy. Big thanks to Tom, ski and others who helped me

 

Screenshot of my basic routing:

 

 

Logic Project:

 

IO_Plugin_Test_4.zip

[nosebagger]

Great news and well done! Hopefully she'll hold together from here.

[RedBaron]

Seems to be holding up so far

 

I've just corrected the above post.

 

The Recording Delay setting appears to have no effect if purely recording to/from Buses using the I/O Plug-in. It is replaced by the Latency Offset (+178 in my case) in the I/O Plug-in on the "2 Bus" Aux. You can still leave the Recording Delay at your usual setting, so if you decide to record from a physical output to a physical input, without the I/O Plug-in, Logic will apply it's round-trip latency compensation as usual.

 

: D

[Eric Cardenas]

The Recording Delay setting appears to have no effect if purely recording to/from Buses using the I/O Plug-in. It is replaced by the Latency Offset (+178 in my case) in the I/O Plug-in on the "2 Bus" Aux.

 

Remember from the other thread:

 

When recording from a bus, Logic assumes that the routing is internal and that there is therefore no IO latency - so Logic doesn't compensate for this.

[RedBaron]

Thanks for re-iterating & clarifying that Eric.

 

I think I've got my head around it now. Just wasn't totally sure how the I/O Plug-in worked in this particular configuration, being that it is connected to a physical input and output. The I/O Plug-in on my output is essentially doing the latency compensation that Logic automatically does with it's inputs in conjunction with the Recording Delay.

 

Also, I didn't want to confuse the issue, but my version of the test project is all digital (Digiface ADAT to ADAT), so the Recording Delay was zero anyway. It just makes it easier to figure out the way Logic works without worrying about offsets and conversion delays etc. It wasn't until I applied it to my baseline analogue configuration that I finally realized the Recording Delay wasn't being used in this situation.

 

It's working sweetly though, I can change my configuration (add/remove hardware inserts, look-ahead plugins), and everything is now recorded in it's original position, fully automatic.

 

Just need to line up my other 14 outs to my summing mixer now Three different audio interfaces with varying latencies over ADAT.

 

For others reading this, the other thread can be found here:

 

Recording from Bus & Count-in

 

Cheers,

 

: D

[Eric Cardenas]

Also, I didn't want to confuse the issue, but my version of the test project is all digital (Digiface ADAT to ADAT), so the Recording Delay was zero anyway.

 

I believe that it is 36 samples with the DigiFace at single speeds. 4 samples of digital reciver TotalMix and digital transmitter. Then the additional 32 samples of Core Audio buffer.

[RedBaron]

The Digiface reports it's latency correctly to Core Audio.

 

With Logic I/O Buffers at 128, that's (2 x 128) + (2 + 24) + (34 + 24) = 340 samples for a digital round-trip. So my Digiface Recording Delay is 0 (Digiface ADAT Out to ADAT In). It just makes it easier to figure out Logic's internals this way.

 

I use HALLab (free with Xcode) to double check:

 

[Eric Cardenas]

So my Digiface Recording Delay is 0 (Digiface ADAT Out to ADAT In). It just makes it easier to figure out Logic's internals this way.

 

Do you mean Logic's Recording delay parameter is set to 0?

Then I understand what you mean.

What I meant was that there is an amount of non buffered latency. Not Logic's setting.

[RedBaron]

When using the Digiface in a digital loopback (ADAT to ADAT), yes. It's -178 when using it with my Prism, which uses it's Firewire buffers in ADAT stand-alone mode. Don't get me started on that!

 

Obviously, this is not a real world configuration, I just did it this way to help me figure out the I/O Plug-in etc.

 

: D