Low Latency Monitoring in Studio

[seanmccoy]

I'm helping a client set up his new system with PT Studio and a Lynx converter/interface, so we'll probably want to use LLM for his tracking sessions. I won't be able to get back onto his system until Friday, and I can't find a fully comprehensive list of feature comparisons between Studio and Flex online anywhere. Can anyone using Studio tell me if the "Allow Sends to Persist During LLM" option is available?

[albee1952]

If your client has a reasonably powerful computer, I would skip LLM and just use a 64 buffer setting

[seanmccoy]

Originally Posted by albee1952

If your client has a reasonably powerful computer, I would skip LLM and just use a 64 buffer setting

He has a new Mac Studio Max, so that's definitely a possibility if I mute the input channels in the Lynx NControl software (plus he's moving from an Omni, so that's how he's used to working anyway). My concern is that, due to his lack of technical understanding, he'll somehow mess up the Lynx monitoring and end up with multiple input signals. Food for thought, though, thanks.

[df76]

"Allow Sends to Persist During LLM" is definitely available and working in PT Studio.

I'm using it while zero-latency-tracking with an RME interface.

[Emi]

Originally Posted by seanmccoy

He has a new Mac Studio Max, so that's definitely a possibility if I mute the input channels in the Lynx NControl software (plus he's moving from an Omni, so that's how he's used to working anyway). My concern is that, due to his lack of technical understanding, he'll somehow mess up the Lynx monitoring and end up with multiple input signals. Food for thought, though, thanks.

I go as low as 32 samples buffer size with an M1 Mac mini with 16gb ram with great stability. Sometimes I even forget I´m at that buffer size while mixing. So with Mac Studio it should go well. I don´t even bother to use LLM.

[EGS]

Originally Posted by albee1952

... just use a 64 buffer ...

Yep

[seanmccoy]

We did end up bypassing the Lynx input monitoring and are going with software monitoring at low buffers, since that's how he was used to working. So far, so good.

[thin ice]

Originally Posted by Emi

I go as low as 32 samples buffer size with an M1 Mac mini with 16gb ram with great stability. Sometimes I even forget I´m at that buffer size while mixing. So with Mac Studio it should go well. I don´t even bother to use LLM.

I was under the impression that the buffer is only relevant when recording and playback is dealt with automatically?

[Emi]

Originally Posted by thin ice

I was under the impression that the buffer is only relevant when recording and playback is dealt with automatically?

It is not automatically, you have to set it up for the task you are doing. If you want less latency than you choose the lowest buffer size, but at the cost of using more cpu power. For mixing it’s better to go for a higher buffer size in order to use the most of your cpu.

[Darryl Ramm]

Originally Posted by Emi

It is not automatically, you have to set it up for the task you are doing. If you want less latency than you choose the lowest buffer size, but at the cost of using more cpu power. For mixing it’s better to go for a higher buffer size in order to use the most of your cpu.

Thin Ice is referring to the dual IO buffer architecture Pro Tools has had since Pro Tools 11, and that dual buffer behavior is all "automatic". If an audio path is in the "high latency" domain it's using the large disk playback buffer size that is 1024 or 2048 samples depending on sample rate, if it's in the "low latency" domain, i.e. is feeding a real time monitoring signal then it's using the IO Buffer size you set in the playback engine. This can be seen at times with the very low CPU overhead/good plugin processing if you don't have any tracks record armed or in input monitoring and no aux tracks feeding to a monitoring path. Then you can change IO BufferSize and it won't make any difference, but enable input monitoring on some tracks and stuff can behave very differently. But many sessions are not set up clean like that, especially not with aux tracks, so you may have low-latency domain stuff being used. This stuff was discussed on DUC a lot, oh a decade ago or so when it was implemented in Pro Tools 11.

All changing the IO buffer size lets you do is set the buffer size for paths where Pro Tools decides to use that, otherwise it's using the large "disk IO" buffer size.