Recording Latency with new Avid Audio Engine

[Ru_C]

Hey all, I just fired up the demo of PT11 Hd on my i7 Macbook pro to give it a spin (using Presonus firestudio 26 i/o ).

The first thing I wanted to test, was this new 'split buffer' system, that apparently allows the track being recorded/monitored to be at a very low latency, whilst the playback tracks were set high.

As I understood it, if I set the playback buffer to 1024, when i arm a track to play/sing though, that track will be dropped to 32samples, whilst other tracks in the session will play back with a 1024 buffer in order to stress the system less?

I've tried this playing the guitar through both Kontakt GTR Rig 5 & Eleven free, & whilst the monitoring is def. much less that 1024, I would say it feels more like 128/256 samples, def not as small as 32 buffer.

Actually *dropping* the buffer size to 32 in the playback engine settings of course makes things feel tight again, but then I'm back pretty much to where I was with PT10 in terms of plugin/NI count.

Am I doing anything wrong here?

[nst7]

You are not understanding how it works. When you drop the buffer to 32 or 64, it's only dropping the buffer on the tracks that you're recording to. All the other tracks are playing at 1024 (or 2048 if you're at higher sample rates). So that's the advantage of PT11.

[Ru_C]

Originally Posted by nst7

You are not understanding how it works. When you drop the buffer to 32 or 64, it's only dropping the buffer on the tracks that you're recording to. All the other tracks are playing at 1024 (or 2048 if you're at higher sample rates). So that's the advantage of PT11.

Ok, you're 100% sure of that? If so many thanks for clearing that up. I'll start experimenting again !

Update: I've dropped the buffer to 64 samples, plugin count is no better than PT10HD on the same hardware.

I'm running a single track of Kontakt for drums, & am playing back three track of Guitar Rig 5 guitars.

When attempting to record a fourth guitar track, I get the old (-6101) error.

Anyone?

[Ru_C]

OK: Update 2..I had a single instance of 'Eleven LE' running in the session too.

When that is removed, all the sudden spikes disappear under PT11.

Is Eleven a known issue?

[Drew Mazurek]

The inout buffer is the only thing the user can set now. The plugin buffer is always 1024 or 2048.

Not sure about Eleven, but I do think 11 still needs some optimization in how it handles the CPU.

[propower]

You don't list speed/age of MBP. Unless you are using very modern hardware my experience is that low buffer recording is spiky and problematic. You are also a bit at the mercy of presonus since they make the actual driver you are using to record through their interface.

FWIW: Try downloading xcode from apple and google how to disable Hyperthreading. Also, IME a 2.6GHz Ivy bridge processor was not up to 96kHz/64buffer recording for me with HD NAtive TB. I have sen some reports of MAvericks helping with this but I have no direct experience.

[mrtomcat]

I read somewhere that the Input buffer setting also applies to Aux Channels, which could explain the error you got... I had the same experience with the error.
When I do NOT use VI's such as Kontakt going over several auxes it works great when I do, I need to increase the buffer.

(32 gig of ram i7 processor)

Can someone clear this up?

[Bobogura]

Originally Posted by Drew Mazurek

The inout buffer is the only thing the user can set now. The plugin buffer is always 1024 or 2048.

Not sure about Eleven, but I do think 11 still needs some optimization in how it handles the CPU.

This is true. But how come the input buffer size still matters when you're not recording?

I get much better plugin performance when setting this to higher settings even when nothing is in input or record enabled.

I thought the whole point of dual buffers was so we could now set the input buffer size low and leave it there so we don't have to change settings all the time like before?

Does not seem to be the case

[Bharath]

Another way to look at this : "live monitoring path" vs "disk track path".

If your signal topology falls in the first case, it has to be in a lower latency path and hence follow the hardware buffer size (or input buffer). If it is the later one, naturally it can be processed at a bigger size (1k or 2k depending on sample rate) since we don't have to worry about "monitoring" latency and we are just reading disk data.

[Bobogura]

Originally Posted by Bharath

Another way to look at this : "live monitoring path" vs "disk track path".

If your signal topology falls in the first case, it has to be in a lower latency path and hence follow the hardware buffer size (or input buffer). If it is the later one, naturally it can be processed at a bigger size (1k or 2k depending on sample rate) since we don't have to worry about "monitoring" latency and we are just reading disk data.

So why does the "input buffer size" still affect CPU performance on the "disk tracks"

I still have to set it higher when mixing and lower when recording. Was hoping I wouldn't have to bother with that anymore.

Thanks