PT outboard latency

a computer-related recording forum with user woes, how-to's and hints
twitchmonitor
re-cappin' neve
Posts: 659
Joined: Thu May 15, 2003 7:00 pm

PT outboard latency

Post by twitchmonitor » Fri Feb 11, 2005 8:34 am

PT LE (5.x and 6.2.3), 001, G4 800

Clearly, sending a track through a piece of outboard gear will induce some latency. And so will just sending a signal out and bringing it back with no outboard equipement in the way. But here's the million dollar question: will it be the SAME AMOUNT of latency?

I'd like to have a processed (outboard gear) track and an unprocessed version of the same track, and I'm thinking that I can avoid any latency induced phasing problems by just sending the unprocessed track out and back, so it's getting the same D/A/D lag time.

Sorry for reposting this, but my last post got zero responses, and it may have been a bit unclear.

Thanks!

wallace
gimme a little kick & snare
Posts: 90
Joined: Tue Sep 02, 2003 1:11 pm
Location: Los Angeles, CA
Contact:

Re: PT outboard latency

Post by wallace » Fri Feb 11, 2005 11:53 am

I'm not quite sure what you're asking.... are you trying to figure out how much latency there is by sending the file out then back in... it's pretty simple to figure out: send track out of the 001 through out 5, then back in to input 5 (or whatever). Then zoom in to the first bump on your wave file and calculate the number of samples between the original and exported track. Then do the same thing for the processed track and see if there is more latency. I don't think there should be, but I might be wrong.

Just shift the processed track forward by the number of samples it's delayed by. For me it's been about 333 samples difference.

twitchmonitor
re-cappin' neve
Posts: 659
Joined: Thu May 15, 2003 7:00 pm

Re: PT outboard latency

Post by twitchmonitor » Fri Feb 11, 2005 1:15 pm

wallace wrote:I'm not quite sure what you're asking.... are you trying to figure out how much latency there is by sending the file out then back in... it's pretty simple to figure out: send track out of the 001 through out 5, then back in to input 5 (or whatever). Then zoom in to the first bump on your wave file and calculate the number of samples between the original and exported track. Then do the same thing for the processed track and see if there is more latency. I don't think there should be, but I might be wrong.

Just shift the processed track forward by the number of samples it's delayed by. For me it's been about 333 samples difference.
No, no. Sorry it's unclear. Here's what I want to do: Have a (1) stereo drum mix, and (2) a stereo COMPRESSED (with outboard compressor) drum mix. Since sending the mix out, say through 3 and 4, through a compressor, and bringing it back in on 3 and 4 is going to induce some latency, I was hoping that I could send the uncompressed stereo drum mix out say, 5 and 6 and then just bring it back on 5 and 6 in. Granted I'm going to degrade the signal in the D/A/D conversion, but I want a real-time latency solution for using an outboard compressor in this application.

Al_Huero
suffering 'studio suck'
Posts: 485
Joined: Thu Sep 25, 2003 9:58 am
Location: Vista
Contact:

Re: PT outboard latency

Post by Al_Huero » Fri Feb 11, 2005 2:40 pm

Is the kernel of this question (and I'd be interested too if so) that if you're using outboard gear as an insert effect on an auxillary input track how to account for latency while mixing? As I understand it, the auxillary track isn't printed; it's basically active during mixing only. In this case, when you don't have a printed track to adjust, can you really account for the latency induced?

twitchmonitor
re-cappin' neve
Posts: 659
Joined: Thu May 15, 2003 7:00 pm

Re: PT outboard latency

Post by twitchmonitor » Fri Feb 11, 2005 3:36 pm

OK, to clarify:

I'm going to bus my drum mix to two stereo aux tracks (but not send the individual drum track to the main output - so basically the drums are only coming through the two auxes), one that will be kept unprocessed, and one that I will compress. When I do this in the box I have to put the compressor plug in on EACH aux and bypass the one on the first aux. This way, both have the same latency, and hence I get no comb filtering between the two.

So now I'd like to do this with hardward instead, but I don't have a spare hardware compressor to send my first aux through, so I'm wondering if I take two cables, patch it out and then back in, if that will be the same amount of latency as the track that I have the outboard comp on.

So basically, does the compressor itself add a significant delay?

trevord
gettin' sounds
Posts: 128
Joined: Thu Jun 12, 2003 2:20 pm
Location: San Jose, CA

Re: PT outboard latency

Post by trevord » Fri Feb 11, 2005 5:14 pm

first off the answers is yes - that would account for delay but you would be adding the noise from d to a - the cable noise then a to d

BUT (the big but here :) )

the following applies to intelligently written DAW software only

your daw software should already account for any latency and you should not see it anywhere
(if it cliams to be "sample accurate" that is)

remember there is a huge amount of latency in anything involving your computer

but (as fas as computer -> external effect -> computer goes)
you DAW software takes these delays into account
when your DAW is playing back it is not like tape..
you DAW has calculated everything way in advance and syhnchronizes everything according to the buffer setting you chose.
if you chose 5 ms -
the DAW sends the audio out
then knows to update the moving pointer 5 ms from now
the same applies to the input data
when the computer gets chunk of data
it knows this is the chunk of data from 5 ms ago and positions it correctly

if you DO notice some offset - there should be a setting somewhere in your DAW setup to add a "fudge factor" to the buffer number - set this correctly and you should not have to do
anything else.


NOTE: this does not apply to
instrument -> computer effect -> speaker
in this case you cant help the huge (relatively) delay
in general the rule is - once the computer initiates the action - it can account for any delay no matter how large the delay (once its constant) or how slow the computer is.

but once the action is initiaited from outside the computer - you need the raw speed to reduce the buffer size.

now i say "intelligent" because there a some big/popular brands of software which do not do this correctly

in short
1) you should not see a sample offset
2) if you do - fix it by adjjusting the DAW buffer settings - not by wave twiddling

hope it helps
trevor

twitchmonitor
re-cappin' neve
Posts: 659
Joined: Thu May 15, 2003 7:00 pm

Re: PT outboard latency

Post by twitchmonitor » Fri Feb 11, 2005 5:47 pm

Thanks, Trevor! I'm running Pro Tools LE.....is this one that I need to futz with or should it do it itself?

trevord
gettin' sounds
Posts: 128
Joined: Thu Jun 12, 2003 2:20 pm
Location: San Jose, CA

Re: PT outboard latency

Post by trevord » Fri Feb 11, 2005 7:30 pm

as far as i know ALL major software handles audio buffering correctly
so go ahead - if you want, you can increase the buffer size for this operation to 10 ms just to be safe.

the problem usualy comes from
1) os - xp and osx being more complex and security minded have delays which vary and cause problems - either use a large buffer or make sure to kill all other programs
note i said "vary" not large delay - the problem comes from the delay changing not the size of the delay
2) many programs have trouble synchronizing a very large ( 1 or 2 secs) of buffer delay to other events (midi and screen/gui operations) i think all pt software falls into this category (but these things are fixed every release so the latest may be ok)

i would recommend only playing the tracks you are processing externaly to avoid hic-cups

let us know how it goes - what we are talking about is the basis of DAW multi-tracking - if it doesn't work you may need some adjustments to your DAW software buffers settings and/or hardware settings

the great thing about pt le is since the hardware and software come from the same manufacturer most likely they are in perfect sync ( i think they even automaticaly adjust - but i could be wrong)

brew
pushin' record
Posts: 284
Joined: Thu Aug 14, 2003 2:06 pm
Location: Brooklyn

Re: PT outboard latency

Post by brew » Fri Feb 11, 2005 7:56 pm

right, DA -> outboard -> AD is equal to DA -> AD for practical purposes. this is because the signal is analog (electrical) and therefore approaches the speed of light, there is some delay but it's on the order of micro seconds or less. My figures could be wrong here, but basically nothing to bother with. There was a topic about this at George Massenburg's forum but I can't seem to find it. nobody ever really worries about delay with analog processing.

you're doing parallel compression here. if your results are good then it is good, but i try to avoid unncessary conversions. i think if you want to do this without that conversion, your only option is to record the compressed signal and then line it up with the uncompressed. not sure if LE has latency compensation on hardware inserts--in that case you could do everything in real-time--but i'm pretty sure it definitely doesn't in the plug-in department.

User avatar
Huntlabs
pushin' record
Posts: 287
Joined: Sun Dec 26, 2004 1:18 pm
Location: Portland, OR
Contact:

Re: PT outboard latency

Post by Huntlabs » Fri Feb 11, 2005 10:48 pm

With PT sending DA then back to AD there will be latency. You need to send a click or similar signal out through the gear in question and then back into PT. Recored it to a track. Then zoom in and shift and un-shift until you find the latency amount. It should vary with sample rate.

You are going to have to print it and slide it to get rid of the latency. Otherwise you'll have more latency. The little bit of latency correction in PT takes place when you record a track.

For me, 001 at 44.1 / 24: There is 57 samples of latency when playing to a PT generated click and recording back through the 001. If I do the same thing with my Octopre, lightpipe, there is 80 samples of latency. I run 6.4cs now. When I had 6.1.1 these numbers were slightly higher.

There is no substitute for testing this yourself with your gear. Post us some results.

John
"Add water, makes its own sauce"

www.CRACKERTONES.com

trevord
gettin' sounds
Posts: 128
Joined: Thu Jun 12, 2003 2:20 pm
Location: San Jose, CA

Re: PT outboard latency

Post by trevord » Sat Feb 12, 2005 1:23 am

that is incredible !!
WTF
even my POS cubase with layla 20 running on win 98 se 900 Mhz intel is much much better than that
mines on the order 10 SAMPLES
this is with the ASIO drivers - ASIO drivers can vary with the card manufacturer

that pt delay is on the order of a ms

i dont know about pt, but there has to some buffer adjustment to correct that.
is it constant or does it vary?
if it is constant there has to be a way to adjust for it, somewhere there should be a "sample adjust" which can be either positive or negative, you should adjust this rather than shift the wave by hand

how come simple software has solved this and pt hasnt ?
i assume a little more than 1 ms is not a problem in a playback/recording session

User avatar
Huntlabs
pushin' record
Posts: 287
Joined: Sun Dec 26, 2004 1:18 pm
Location: Portland, OR
Contact:

Re: PT outboard latency

Post by Huntlabs » Sat Feb 12, 2005 9:10 am

This amount of latency, 80 samples at 44.1, is not really noticiable unless you duplicate a track, shift it, and then listen to the comb filtering.

It is constant. But if you add certain plug ins it can drastically increase the latency. Waves L3 bumps it up to over 3,000 samples. Just don't record with mastering plugs in place or you can go "low Latency" to kill the plugs.

There is some correction. The software shifts the recorded track equal to the buffer, forward. Now I think, from 6.1.1 to 6.4cs, they have also accounted for some of the converter latency.

I really started looking into this when I was tracking my band with a click. It just wasn't tight and sounded sloppy. (Not that my band mates are all that good at playing with a click, it is an aquired skill that needs to be practiced and do they practice???? Anyone?)

What happened to me is that the first part gets put down and there was about 90 samples of latency to the click. Next part, do they play with the click or the latency? Keep doing this and it just gets sloppy. Complicating my situation was a Roland V Club Drum kit. There is 130 samples of latency between striking the pad and the signal comming out of it. Add 130 and 90 and that makes: 220 samples at 44.1. That you can hear.

Solution: Learn the latency of your system and MIDI devices and make the appropriate adjustments. Or track everything at once.

You can use a mixer for zero latency monitoring but that doesn't change the recorded latency.

Is that enough info????
"Add water, makes its own sauce"

www.CRACKERTONES.com

User avatar
Huntlabs
pushin' record
Posts: 287
Joined: Sun Dec 26, 2004 1:18 pm
Location: Portland, OR
Contact:

Re: PT outboard latency

Post by Huntlabs » Sat Feb 12, 2005 9:15 am

trevord wrote:that is incredible !!
WTF
even my POS cubase with layla 20 running on win 98 se 900 Mhz intel is much much better than that
mines on the order 10 SAMPLES
Have you tested it? Record a click track then send it out and back in, using a patch chord, and record it to another track. Line them back up. Iy you use a mic and a speaker that introduces some latency too. This can be good to know because that is what the performer is hearing.

Test and then post your results, please.

This is why tape is cool.
"Add water, makes its own sauce"

www.CRACKERTONES.com

trevord
gettin' sounds
Posts: 128
Joined: Thu Jun 12, 2003 2:20 pm
Location: San Jose, CA

Re: PT outboard latency

Post by trevord » Sat Feb 12, 2005 7:07 pm

ok
i just did a test with
PIII 800 Mhz Intel running Win98SE with 1 gig of ram
audio was layla 20 using ASIO drivers
i set the buffer size to 16384 (thats right! 341 ms of delay for buffer alone)

play back thru layal 1.2 into layla 3.4 and recorded

wav offset was 7 samples

this is with n-track which costs $30.

remember the actual delay number is not important
i have a feeling the actual delay is 0 , with some variation
between plus/minus 10 because of variable system issues

the real issue is all software should have a facility for dealing with the constant part of the delay

this is why setting the buffer to be huge absorbs a lot of system delay in the huge time provided by the buffer

low audio buffer settings are only important for realtime situations
1) midi to vsti output
2) virtual knob operation to sound change
3) input -> daw effect -> output


any action from computer to computer is not realtime
once the computer initiitiates an action
and knows the delay the system takes for that action
it can compensate for the delay - larger delay is actual better

for example
you set your buffer to 256 (5ms)
you system (for whatever reason) takes 6.2 ms to do audio processing
you will always have 1.2 ms of delay not expected by the system
(but your vsti and virtual knob response will be sweet)
if you set it to 512 (10ms)
your daw software now expects 10ms - if your system is faster than that - then your computer sleeps while waiting for the next buffer
(but your may hear a delay from midi keyboard key press to vsti output
and more relevantly punch-ins will be a nightmare)

so for playback-record tracking large buffers are best
however
since buffer increments are usualy doubled
256,512,1024,2048 samples
even tho you only need an extra fraction of a ms, you may have to double the delay just to get it
so most intelligent :) software has an adjustment (or compensation or whatever) which adds just a small increment to the expected delay

it is best if i quote from the n-track users manual on this - it is a good explanation, but to summarize
1) use a large buffer for playback-record tracking
2) see if you can do smaller adjustments to expected delay - RTFM
3) it is not the size of the delay that is important - but whether your daw software is configurable to accomodate the delay
With some soundcards new recordings don?t sound perfectly in sync with the previous tracks because of the inability of the soundcard to start the recording and the playback at the very same time. If you notice a sync problem in which recorded tracks sound constantly (i.e. with equal delay during the whole length of the recording) too early or too late with respect to existing tracks in the song you can use the compensation parameter in the Preferences/Wave devices/Advanced dialog box to compensate for the problem. Use a negative value if the new tracks sound delayed or a positive value if new tracks sound too early (the program will shift new tracks to the right by the amount specified, or if the compensation is negative the shift will be towards the left). The default value of 0 will work in almost all systems.

Usually there?s no need to worry about the compensation settings, so read this only if you can hear a shift between the recorded tracks,
If you experience sync problems try unchecking both the Preferences/Options/Use system timer for checkboxes, then set the Preferences/Recording settings/Hide lag indicator.. parameter to 1.
During a recording, notice the value that will appear near the "lag" writing on the time window on the program?s toolbar.

If the lag value is constant throughout the duration of the recording it can be compensated with the compensation setting discussed above. If the lag value grows constantly during the recording the problem is most likely caused by the soundcard sampling frequency not being perfectly constant or by a difference in the soundcard?s recording and playback sampling frequencies. When this occurs the problem can?t be fixed using the compensation parameter and the program may not work properly so it may be necessary to change soundcard.

Note: the lag values reported are based on the recording and playback position information reported to the program by the soundcard. This information may be incorrect so it may lead to think that sync problems exist while it?s just that the recording and/or playback times are being reported incorrectly. It?s very important to double check with your ears if the lag values reported make sense.

twitchmonitor
re-cappin' neve
Posts: 659
Joined: Thu May 15, 2003 7:00 pm

Re: PT outboard latency

Post by twitchmonitor » Sun Feb 13, 2005 9:22 am

brew wrote:right, DA -> outboard -> AD is equal to DA -> AD for practical purposes. this is because the signal is analog (electrical) and therefore approaches the speed of light, there is some delay but it's on the order of micro seconds or less. My figures could be wrong here, but basically nothing to bother with. There was a topic about this at George Massenburg's forum but I can't seem to find it. nobody ever really worries about delay with analog processing.

you're doing parallel compression here. if your results are good then it is good, but i try to avoid unncessary conversions. i think if you want to do this without that conversion, your only option is to record the compressed signal and then line it up with the uncompressed. not sure if LE has latency compensation on hardware inserts--in that case you could do everything in real-time--but i'm pretty sure it definitely doesn't in the plug-in department.

I screwed around with it last night and found that the DA - compressor - AD track adn the DA - AD track were just about perfectly lined up. So I think I'm just going to run the mix session with it patched that way, and then when it's time to bounce, I'm going to print the comprssed track and not DA - AD convert the first track. A minor hastle, but that'll let me use an outboard comprssor, save DSP (from not having to use 2 plugs) and maintain the audio quality. Cool.

Locked

Who is online

Users browsing this forum: No registered users and 8 guests