Low latency mode ?

I am starting to get really tired of the UAD latency. It is ok when mixing but not during the production phase, introducing huge latency when I use hardware synths coming "live" into my Pro Tools mixer. Sure Pro Tools is compensating for the delay but when I play or record MIDI or even virtual instruments there is a huge lag...when using UAD plugins.
So...is there anyone outthere that is running ALL the UAD plugins always in low latency mode ?!?!

I am willing to pay a lot to get rid of the DSP cards and use native versions of the excellent UAD plugins instead.

I'd like to know the answer to this too? Is the UAD2 Octo for example, useless at running plugins while still trying to achieve low latency tracking and vsti's?

Al

Are you only using a UAD-2 Satellite for DSP? Using a UAD-2 PCIe card allows you to use "LiveTrack" mode and you can eliminate the inherent plug-in buffer latency (1x audio card buffer size)) between the DAW and the Satellite. FYI, LT mode is not available with FW devices because of the additional buffering (512 samples) required when using FW DSP devices. With a UAD-2 PCIe card, a low latency ASIO audio card (64 samples) and LT mode enabled you can run UAD plug-ins pretty much like native, latency wise. You would still have plug-in latency due to any upsampled plug-ins (whether native or DSP). Also some DAW apps require the "Extra Buffering" option enabled on the UAD-2 which adds another 64 samples.

Example latency values: 44.1K @ 64 samples:

Using a Satellite:

1176 Legacy with extra buffering enabled:

64 (audio buffer size) + 64 (Extra Buffering) + 512 (FW DSP latency) = 640 samples latency per 1176 legacy plug-in instance

Neve 33609 with extra buffering disabled:

64 (audio buffer size) + 512 (FW DSP latency) + 55 (upsampling latency) = 632 samples per Neve 33609 instance



Using DSP PCIe:

1176 Legacy with extra buffering enabled:

64 (audio buffer size) + 64 (1 x buffer size) + 64 (Extra Buffering) = 192 samples latency per 1176 legacy plug-in instance

1176 Legacy with LT mode enabled & extra buffering disabled:

64 (audio buffer size) = 64 samples (same as using native)

Neve 33609 with LT mode enabled & extra buffering disabled:

64 (audio buffer size) + 55 (upsampling latency) = 119 samples latency per Neve 33609 instance (same as native)


Of course, this inherent plug-in latency conundrum was why UA developed the Apollo for a realtime UAD processing experience. Faster than even using native as you totally bypass the unavoidable RT latency associated with using audio cards.


Cheers,

Billy Buck

qbaser said:

I'd like to know the answer to this too? Is the UAD2 Octo for example, useless at running plugins while still trying to achieve low latency tracking and vsti's?

Al

Click to expand...

If you use an Octo PCIe DSP card (avoid FW) you can achieve low plug-in latency for input monitoring (not real-time like an Apollo), but close to native by using Live Track mode and a quality low latency audio card (64 samples).

Cheers,

Billy Buck

Tracking through plugins natively is nearly impossible—UAD or not. Apollo is great. Almost like a PTHD situation.

Live Mode halves the latency. That said, I've never met ANY native solution with latency I could personally be comfortable with while using any type of native plugins. I'm in a minority here, however. Most people get by fine even at 128 buffer on a FireWire interface. That's around 11ms real latency.

TDM to the rescue. 2ms.

billybk1 said:

Are you only using a UAD-2 Satellite for DSP? Using a UAD-2 PCIe card allows you to use "LiveTrack" mode and you can eliminate the inherent plug-in buffer latency (1x audio card buffer size)) between the DAW and the Satellite. FYI, LT mode is not available with FW devices because of the additional buffering (512 samples) required when using FW DSP devices. With a UAD-2 PCIe card, a low latency ASIO audio card (64 samples) and LT mode enabled you can run UAD plug-ins pretty much like native, latency wise. You would still have plug-in latency due to any upsampled plug-ins (whether native or DSP). Also some DAW apps require the "Extra Buffering" option enabled on the UAD-2 which adds another 64 samples.

Example latency values: 44.1K @ 64 samples:

Using a Satellite:

1176 Legacy with extra buffering enabled:

64 (audio buffer size) + 64 (Extra Buffering) + 512 (FW DSP latency) = 640 samples latency per 1176 legacy plug-in instance

Neve 33609 with extra buffering disabled:

64 (audio buffer size) + 512 (FW DSP latency) + 55 (upsampling latency) = 632 samples per Neve 33609 instance



Using DSP PCIe:

1176 Legacy with extra buffering enabled:

64 (audio buffer size) + 64 (1 x buffer size) + 64 (Extra Buffering) = 192 samples latency per 1176 legacy plug-in instance

1176 Legacy with LT mode enabled & extra buffering disabled:

64 (audio buffer size) = 64 samples (same as using native)

Neve 33609 with LT mode enabled & extra buffering disabled:

64 (audio buffer size) + 55 (upsampling latency) = 119 samples latency per Neve 33609 instance (same as native)


Of course, this inherent plug-in latency conundrum was why UA developed the Apollo for a realtime UAD processing experience. Faster than even using native as you totally bypass the unavoidable RT latency associated with using audio cards.


Cheers,

Billy Buck

Click to expand...

Thanks Billy for that very detailed and informative reply.

I'm unclear on one thing, perhaps you could clarify, but let me first explain my example situation.

With my MR816 and Cubase 7, I'm lucky that I can track in realtime at 64 buffers with about 2 Ms latency. Now whilst tracking, I added several Waves 'Channel G strips' and 'trueverb' on about 6 of the track channels allowing me to monitor through Cubase with those great plugins (so that's 12 Waves plugins in total).

The result is that the audible 'delay' in the cans for vocalists is negligible. I also notice that in the 'plug-in information' window within Cubase, it states a latency of "1" for each of those plugin instances. I'm not sure if this "1" means 1 sample or "1 ms" or if in fact this figure is baloney! as like I said, there is no perceived audio delay in the cans which I'm happy about.

My question Billy is, now I am wondering, if I were to buy a UAD2 OCTO PCIe card and then track using the same 64 buffer rate on my MR816 unit, what figure of latency will be added in the 'plug-in information' window in Cubase if I were to say add a UA Channel G strip plus Lex 224 on six channels in realtime? And what roundtrip latency will be added? Are you saying it would be zero added latency with the UAD2 PCI card? If there is zero added latency I'll buy a card. Please can you clarify thanks.

Thanks
Al

p.s. On a side note, I did actually try the Apollo unit for a week and was really disappointed at the latency of the unit itself. The Apollo drivers in my opinion are not developed quite enough to drive latency low enough for some VST instruments (e.g. triggering Superior drummer with my E-Drums). Although the Apollo's zero latency monitoring feature does work very well I have to say, the actual Apollo card latencies are not low enough, compared to my MR816CSX interface. See my attached graphic (I compared using 32,64 and 128 buffers at 88khz). It's a dealbreaker for me as if Apollo drivers produced ultra low latency like the MR816 unit does then I'd have one in a heartbeat.

qbaser said:

My question Billy is, now I am wondering, if I were to buy a UAD2 OCTO PCIe card and then track using the same 64 buffer rate on my MR816 unit, what figure of latency will be added in the 'plug-in information' window in Cubase if I were to say add a UA Channel G strip plus Lex 224 on six channels in realtime? And what roundtrip latency will be added? Are you saying it would be zero added latency with the UAD2 PCI card? If there is zero added latency I'll buy a card. Please can you clarify thanks.

Click to expand...

You would get added latency in that scenerio, because those two particular plug-ins are upsampled to 192k. Even if they were native (and upsampled) you would get added latency because of upsampling. If they were not upsampled and you used the LiveTrack mode (option that is enabled on each plug-in GUI), then there would be zero additional delay. There is an upsampling latency value guide in the UAD System Manual for each plug-in that is upsampled. This value can change depending at which sample rate you are using. At 88k, the UA Channel Strip would add 13 samples plugin latency and the Lexicon 224 would add another 90 samples.

p.s. On a side note, I did actually try the Apollo unit for a week and was really disappointed at the latency of the unit itself. The Apollo drivers in my opinion are not developed quite enough to drive latency low enough for some VST instruments (e.g. triggering Superior drummer with my E-Drums). Although the Apollo's zero latency monitoring feature does work very well I have to say, the actual Apollo card latencies are not low enough, compared to my MR816CSX interface. See my attached graphic (I compared using 32,64 and 128 buffers at 88khz). It's a dealbreaker for me as if Apollo drivers produced ultra low latency like the MR816 unit does then I'd have one in a heartbeat.

Click to expand...

I don't use E-Drums, but using the new virtual I/O feature on the Apollo, I am able to use my MIDI keyboard and play a VSTi, like EZKeys for instance, and record/monitor with UAD plug-ins in the Apollo console with no perceptible delay. Everyone has different needs and work flows, so I would imagine there are cases when the Apollo is just not the right choice.

Good luck,

Billy Buck

billybk1 said:

You would get added latency in that scenerio, because those two particular plug-ins are upsampled to 192k. Even if they were native (and upsampled) you would get added latency because of upsampling. If they were not upsampled and you used the LiveTrack mode (option that is enabled on each plug-in GUI), then there would be zero additional delay. There is an upsampling latency value guide in the UAD System Manual for each plug-in that is upsampled. This value can change depending at which sample rate you are using. At 88k, the UA Channel Strip would add 13 samples plugin latency and the Lexicon 224 would add another 90 samples.



I don't use E-Drums, but using the new virtual I/O feature on the Apollo, I am able to use my MIDI keyboard and play a VSTi, like EZKeys for instance, and record/monitor with UAD plug-ins in the Apollo console with no perceptible delay. Everyone has different needs and work flows, so I would imagine there are cases when the Apollo is just not the right choice.

Good luck,

Billy Buck

Click to expand...

I'll check out those individual sample figures for each plugin in the manual. It is a pity that latency is added, kind of makes the unit unusable for my situation then.

Regards the Virtual I/O feature of the Apollo, I'm afraid what you say isn't actually correct. The path is, midi keyboard > DAW > Apollo Console (using Virtual I/O). So yes, although you can add effects with no extra latency when the signal is in the virtual console, it does not mean however that you can play and midi live with no latency as the latency is already inherent in the system chain before it reaches the virtual I/O. And the latency I am referring to is entirely down to how good (or bad) the Apollo drivers are. Yes, the driers are fine for most keyboard midi tasks however, not good enough for E-Drum triggering, even at the lowest buffer rate. This is not my opinion, it's a fact of how Apollo works.

qbaser said:

I'll check out those individual sample figures for each plugin in the manual. It is a pity that latency is added, kind of makes the unit unusable for my situation then.

Regards the Virtual I/O feature of the Apollo, I'm afraid what you say isn't actually correct. The path is, midi keyboard > DAW > Apollo Console (using Virtual I/O). So yes, although you can add effects with no extra latency when the signal is in the virtual console, it does not mean however that you can play and midi live with no latency as the latency is already inherent in the system chain before it reaches the virtual I/O. And the latency I am referring to is entirely down to how good (or bad) the Apollo drivers are. Yes, the driers are fine for most keyboard midi tasks however, not good enough for E-Drum triggering, even at the lowest buffer rate. This is not my opinion, it's a fact of how Apollo works.

Click to expand...

Yes, that is true. In your situation the Apollo is not a good fit. The Apollo's real forte is recording/monitoring live musicians using acoustic instruments/vocals with it's UAD real time processing. Then the audio driver latency is not of any concern as you are hitting the UAD plug-in processing before the audio drivers are even involved (Live signal into Hi-Z/Mic/Line inputs -> UAD processing -> audio drivers -> DAW). There is not any RT latency even involved and it is how the Apollo can get near real-time plug-in latency, by doing it on the front end. That is really what the Apollo is designed for and excels at.

Cheers,

Billy Buck

Thanks a lot for the answers !
However I am on Quad Satellite...I just figured out that Live Track mode is not available for Satellites and sure I can see why due to the firewire protocol. But the discussion is very interesting anyway so how much native CPU hit can I expect when using Live track mode with a Quad PCIe card. I am on a Mac Pro hexacore running Pro Tools TDM 10.3.6 btw.

Hi qbaser
I also use MR816x and i just wanted to tell you that the latency reported from cubase for this unit does not seem to be correct. I tested all the different buffer sizes with an utility called "CEntrance ASIO Latency Test Utility". The thing is that the mr816 has hidden buffers inside the firewire interface or something, and the actually lowest latency i was able to get, was using 128 buffers wich i think gave around 9-11 ms (i dont remember the exact numbers) any buffers lower than that will increase the real latency from the unit itself. But I dont belive this apply to the extra latency added from uad plugins. This experience is only based on the results given from the CEntrance utility, but i think its reliable. Just thought you might wanna know