Avid Pro Audio Community

Avid Pro Audio Community

How to Join & Post  •  Community Terms of Use  •  Help Us Help You

Knowledge Base Search  •  Community Search  •  Learn & Support

Avid Home Page

Go Back   Avid Pro Audio Community > Legacy Products > Pro Tools 11

Thread Tools Search this Thread Display Modes
Old 04-17-2013, 06:00 PM
Brock Mixwell Brock Mixwell is offline
Join Date: Jan 2013
Location: Perth
Posts: 54
Default Re: Who else doesn't get how different input and output buffers shall work?

Originally Posted by DAWgEAR View Post
How is this going work with input monitoring through PT?

Let's assume the input buffer is 32 samples and the output buffer is 1024 samples and you are recording the talent who is singing along to prerecorded tracks. Using the karaoke analogy, the playback of the tracks can be compensated for but how about the live input? Doesn't that need to pass through the output buffer before the talent can hear his/her own voice?

Or is it implied that the input is going to be sent through an (separate?) output buffer of 32 samples? And that the compensation of the prerecorded tracks will take 64 samples into account.

Apologies if this is a stupid question.
I think the confusion here is coming from the terms input buffer and output buffer

In pro tools 11 there is 2 buffers

1) a low latency buffer (eg 32 samples) - this has an input buffer and an output buffer; any track that is in record/input monitor goes in an out through this buffer at low latency, and in the case of a VI just goes out through the ll buffer thus giving low latency when playing vis etc

2) a high latency buffer - this is the "playback buffer" any thing that is playing back and not in record/input monitor goes out through this buffer thus giving more available power for plugins etc

The system knows what both of these buffers are and keeps them in sync using delay compensation e.g. playing back the tracks from the playback buffer early.

Logic, samplitude, sequoia, cubase, nuendo all work in this way to a certain extent.
Reply With Quote
Old 04-17-2013, 06:38 PM
nigelpry's Avatar
nigelpry nigelpry is offline
Join Date: Dec 2008
Location: Home
Posts: 2,154
Default Re: Who else doesn't get how different input and output buffers shall work?

bortraws ...

Although the exact maths are largely irrelevant, I think your description may not be quite right. And I think the last sentence of nst7's analogy may get it wrong too.

The point is, what I suggested earlier in the thread involves making the adjustments live, which seems to make more sense than moving things around afterwards. Of course I may be wrong, but I think it makes more sense.

All in all, exactly how it does it may be less important that the fact that it does it, but seeing as you've had a go at explaining, I'll have another go, using your figures to explain what I think is happening.

I think, from what you are saying, that you believe the previously recorded material is played back 1024 late, and the new material is therefore recorded 1024 late, plus an additional 32 late caused by the input buffer. When recording is stopped, pro tools then moves the new audio 1024+32 earlier so as to bring it into alignment with the previously recorded audio.

Am I interpreting you correctly?

The question is, why have a process that involves moving audio after recording stops at all.

Lets use your 1024 sample output buffer and 32 sample input buffer examples, and discard all the other complexities for the sake of this post.

Now, just for one minute, imagine a perfect world in which we were able to set the input buffer to 0 (zero) samples.

If the input was sent to the output with 0 delay, and the previously recorded audio is played back with 1024 delay, then why not play back the previously recorded audio 1024 early, so it arrives at the output at exactly the same time as the input.

Thus if the input is going to the output with 32 delay, then the previously recorded audio would be sent out 1024 early and 32 late so the timing still matches.

In that case, if it originally was going to be 1024 early and it now has to be 32 later than that, then it will need to be 1024 -32 early, which = 992 early.

That, I think, is how the different input and output buffers work, it's something that happens live while recording.

In my scenario, no moving of audio has to be done after recording stops to bring it into alignment, as it is already placed at exactly the correct place in time. This also means that as the audio waveform is drawn on screen during live recording, it is automatically time aligned, whereas in your scenario, the time correction would be done after recording stops, so the live recording waveform would be misaligned when first drawn. Unless PT didn't move the audio until recording stops but does recalculate the screen drawing position live. That just seems a bit clunky.

The initial delay before playback starts is the buffer being filled, but actually, if you think about it, that doesn't help us to resolve one way or the other whether your idea or mine is correct. Is everything recorded late and shunted into the position afterwards, or is prerecorded material played back early so that the new material is recorded at the correct position straightaway.

Actually I think this is the proof that I'm on the right lines, but tell me if you think I'm wrong.

Lets say you're just playing back material, not recording, and you have a 1024 buffer setting. Or there is no recorded material, just the click plugin instantiated. Now Press play. There may be a short delay before playback starts, but ignore that.

Watch the playback cursor move across the screen. Doesn't the audio you hear match the cursor position on screen? If it does, then it must be being played back 1024 early, so it arrives at your ears at the same time as the cursor reaches that point on the timeline. Otherwise, it would arrive at your ears 1024 samples after the cursor passed the same point on the timeline.

I rest my case, unless someone would care to point out what an idiot I am, having missed some significant part on the construct completely ;-)
Reply With Quote
Old 04-18-2013, 01:11 AM
bortraws bortraws is offline
Join Date: Jul 2003
Location: Amsterdam, The Netherlands
Posts: 347
Default Re: Who else doesn't get how different input and output buffers shall work?

Your 'real-time' solution would need PT to look ahead for the plugin processing costing extra CPU overhead.

Automatically shifting the audio earlier in time when finished with recording is the easiest and most CPU efficient way of doing it. And it can be done sample accurate so no problems there. The delay could be 4000 samples or even seconds. It wouldn't matter. This only gives you an initital delay when starting to record and no more than the amount of samples from the input buffer as your monitoring delay. This releases the strain on the processor giving you all that extra power for plugins. Best solution IMO.

But we'll have to wait and see how it's done.

Last edited by bortraws; 04-18-2013 at 02:01 AM.
Reply With Quote

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Help! I can't get my main output to work, and I can't make a stereo output! oceanlove_1 Pro Tools 9 1 06-27-2011 06:23 AM
Out of System Exclusive Output Buffers James and Julieah Pro Tools M-Powered (Win) 0 01-22-2007 11:27 PM
input-output buffers - Compensated for??? Dunewar Tips & Tricks 1 01-27-2006 05:30 AM
Can I use a PA output as an input for Mbox? dklcn 003, Mbox 2, Digi 002, original Mbox, Digi 001 (Win) 5 12-12-2005 03:19 PM
Please help, no output / input from 001 jdavis74 003, Mbox 2, Digi 002, original Mbox, Digi 001 (Mac) 3 04-03-2003 08:18 AM

All times are GMT -7. The time now is 07:13 AM.

Powered by: vBulletin, Copyright ©2000 - 2008, Jelsoft Enterprises Limited. Forum Hosted By: URLJet.com