Who else doesn't get how different input and output buffers shall work?

[Brandonx1]

I have no real info either but if the delay comp for the longest delay in the session in 512 samples, and you put a track into record, the entire session just has to be shifted 480 samples early to stay in time. I'm guessing that's how it's done. I think if you use a plug in on a 32 sample buffer track that adds delay, you are going to have a delay in the record track. Again, just a guess.

[nigelpry]

Was starting to answer this then saw propower's comment ...

It's the only way possible really if you think about it ..... without understanding the precise technicals ...

You'll only be able to set the input buffer, you set it as low as is stable on your system

The higher playback buffer latency and potential timing mismatch of playback must be resolved by playing out the tracks earlier in time by precisely the the difference between the input and output latencies.

The cool bit, and the bit I don't technically understand (and actually don't need to understand so long as it works) is that Avid say the output buffer latency is managed 'dynamically'.

So, pro tools will be dynamically changing how early to play back based on other real time pressures on the system.

This is different to delay compensation in Pro Tools, which is about compensating for delays caused by plugins inserted on tracks, and which can be different on every track if you have different combinations of plugins on each. In that case, put simply, pro tools works out how much plugin latency is on each track.

You choose which delay compensation setting you want, so pro tools knows how many samples of delay tracks must be played back with.

Pro tools then delays each track by whatever make up amount is needed to bring every track into alignment. Say you select 4096 samples as your delay compensation setting. All tracks will be played back with that amount of delay (remember this is not yet about hardware buffer latency, just plugin delay compensation).

If one track has no plugins on it, and so there is no plugin delay incurred, then the delay compensation engine will shunt playback so it plays 4096 samples later. If another track has a handful of plugins that cumulatively cause 4000 samples of delay of that track, then the engine will shunt playback of that track 96 samples later. So both tracks play 4096 samples late and are in time with each other. Then, I'm guessing, they are all sent for playback 4096 samples earlier than they look to be on the timeline, so they come out at the right time.

Now thinking about that in relation to output buffer latency, pro tools will work out much output buffer latency is need 'dynamically' based on other pressures on the system. Lets say that at a point in time it figures 1024 samples to be the appropriate buffer size. If you've set the input buffer to say 64 samples, that's the delay the performer is going to hear in their headphones. You send out the playback audio 960 samples early, and it should arrive at the headphones at the same time as the input.

It's more complicated than that, of course, because with a 64 sample input latency you don't hear the live input come back out after 64 samples. There is also some output latency caused by it going through output part of the system too.

The principle is ... work out how many samples of delay will occur for a live input coming back out through the digital to analog convertor. That will be based on the input buffer setting specified by the user, plus some amount caused by the hardware itself. Then, work out how much output buffer latency is needed for playback audio in order for the whole system to be stable. Then playback the audio the required number of samples early so that playback audio and live input audio appear at the audio outputs at precisely the same time.

Do we need to know it in more detail ... I don't. Even if my description is technically incorrect, i don't really car too much in this case. I'm happy knowing that pro tools is taking some factors into account and then making adjustments to ensure that live input audio and playback audio are perfectly in time with each other. And also that when recording, it takes some factors into account to ensure that the recorded audio is placed on the timeline precisely in the correct place to line up with already recorded material.

[Sardi]

I don't recall them saying anything about tracking at low latency (32 buffer for example) with heavy delay inducing plugins instantiated. I don't believe this is possible. I think they're implying you can't have plugins incurring delay on that track otherwise that adds to the system buffers delay.

What I believe is that you can continue to track at very low latency even if your session is running a lot of plugins and tracks which would normally mean you had to back your buffer off.

If they've managed to allow you to track with say Autotune that incurs delay in realtime without the delay, I'll be gobsmacked. I don't see how that is technically possible.

[Dism]

Originally Posted by Sardi

If they've managed to allow you to track with say Autotune that incurs delay in realtime without the delay, I'll be gobsmacked. I don't see how that is technically possible.

That's what I'm saying!

If I can have my lowest buffer running 24/7 and never get a CPU spike or a loss to latency, I will be a happy camper.

[nst7]

So yeah, I agree that the type of plugins that you can use won't be any different than the limitations now. Just like now, you can't really use an L2 or Autotune 7 on the track you're recording onto, because of the delay, you'll have the same problem on the new system.

But you'll still be able to use most EQ's, compressors, reverbs, or amp sims that have little to no latency, just like now.

The benefit with the new system is that you'll be able to do it much more and with much more going on than before because of the processing.

[propower]

Yes !! as others have said -- if I can just leave the input buffer at 32 track through a simple EQ or comp or light load VI and no big deal on system load than this will be fantastic! Buffer = 16 looks nice too eh

[P,B,S]

Originally Posted by Sardi

I don't recall them saying anything about tracking at low latency (32 buffer for example) with heavy delay inducing plugins instantiated. I don't believe this is possible. I think they're implying you can't have plugins incurring delay on that track otherwise that adds to the system buffers delay.

What I believe is that you can continue to track at very low latency even if your session is running a lot of plugins and tracks which would normally mean you had to back your buffer off.

If they've managed to allow you to track with say Autotune that incurs delay in realtime without the delay, I'll be gobsmacked. I don't see how that is technically possible.

I few possibilities.
Has anyone actually seen this yet even on film.
Or is this something they are rushing to do now, just to stall the release of 11.
or You know delay comp and disc cash.

HOW ABOUT PLUGIN CACHE BUFFERING !
Instead of printing effects to tape or stems.
It prints them in PLUGIN CASHE
same goes for automation that is supposed to be the same every time.
Maybe PT instead of rendering everything it will CASHE things to there own sub categories.

Which iswhat would have to happen to make a offline bounce of 150 the speed of reel time. Even the most bad ass cpu cannot handle that in just micro machine speed reeding times.
Unless avid redefines the drive in a totally new unreleased product.

They have said these things are possible but they didn't say it would be just automatic. Maybe we will have to store our own cashe data for the complex parts we know would bog down a system . Not the entire selection just enough to let PT keep up.

Im a total cpu idiot but that makes sense to me.

[Sardi]

Well I do know that this feature is definitely in standard PT11. Disk cache is still a HD only feature.

If it works in a way you're suggesting, I'm surprised they gave it to standard PT. Solid low latency tracking has always been one of the main draw cards for HD.

TBH, I don't think what you described is how it would work. That would be relying on RAM and not every machine would have the same amounts of RAM. This feature would have to be consistent across the board.

[Marsdy]

Has anything been mentioned about tracking/monitoring through native plug-ins with this new dual buffer arrangement?

[mykhal c]

nah...and IMHO i don't think that's what Avid is gettin' at with the dual buffering system. low latency thru plugins is still a DSP thing...again IMHO