Lowest latency possible using plugin in real time

[hommeout]

Hi Guys

Am using DP for the last 10 years and I never had any problem with it.
For the first time I need to track using 1 plugin in real time and I would like to have the lowest latency possible,the result I have right now is "usable" but I would like to know if I can get better.
Here is my system:
Am using DP6.03 on a MacPro 2X2.66 with 5 GB memory with a 10 000rpm hard drive,my interface is a Motu 896HD but am using external preamp and converter(Mytek,API).
My DP setting(When am tracking through effects) is buffer size=64,Host buffer multiplier=1 and work priority=High
My question is:What can I do to lower my latency??
Am open to everything.
Let me know!!

[micihch]

64 samples is very low, that's about 1.5 milliseconds, about 3ms roundtrip latency plus plugin delay if I'm correct.

You could raise the sample rate to 96khz, that would about half the latency.
But it also depends on the latency of the plugin you're using!

If your system can handle the 64 samples without glitches there's not much you can do to go lower. But remember: even most hardware synths have a much higher latency.
If you are very sensitive to latency (there's a lot of variation among musicians), I'd also avoid using headphones.

[hommeout]

Thanks micihch

I've calculate that my actual lowest latency is about 10ms(out of the plugin) using my setup(Without any glitches).
I know it's already quite low but it's still quite noticable and it's bothering me.
Do you know if I could have a good improvement with the lastest Macpro(Faster memory,faster front bus.....)???
Am just asking,am not that deseparate yet!!

[micihch]

Depends on the plugin. There are plugins that have an 'intrinsic' latency due to their architecture/synthesis method/technology.

Is it a synth plugin? You also have to take the MIDI latency into account, i.e. from playing the key till your plugin sees the generated MIDI message.

If you're down to the lowest possible buffer setting (64 samples), you can't do much more, and your machine still state of the art for audio.

I'm no MIDI expert, but maybe you can squeeze out a few more milliseconds by using a keyboard that is as fast as possible in generating and sending MIDI messages.
I once read that the newer keyboards that can send MIDI over USB are faster, but I don't have any experience with them.

You could also ask the manufacturer of your plugin if a faster machine makes any difference, but I highly doubt it, because you already have a high end Mac.

[David Polich]

You must mean VI's (virtual instruments) - not plug-ins. Plug-ins don't
normally introduce latency because DP has automatic delay compensation.

Buffer of 64 is already too low. I'd never go lower than 128.

There is really only one solution, which I've recommended many many times
here - get another computer to run VI's. Get an audio/MIDI interface for that computer. Hook it up via MIDI like any hardware synth. Buss the
audio from the second computer back into DP. Presto - no latency, even
at higher buffer settings.

Even if I had a new 12-core Mac Pro, I still would run all my VI's on
a second computer.

[magnumpraw]

That's not quite correct David and is actually more latent assuming the same buffer size on your main computer. Using a second computer bussed back into DP, you have these latencies to consider.

1. The MIDI latency getting getting to the 2nd computer (even hardware has some though it's very small)

2. The buffer size of the audio card on the 2nd computer. Depending on the power available on this computer, you may not get it lower than 128 or 256.

3. The buffer size of the audio card on DP.

2 and 3 are the main considerations. If you have a buffer setting of 128 on both your slave and your main computer, you will be getting a combined latency of 384 buffers from when you strike the note till you hear it.

Here's why:
-You strike the note.
-The MIDI is sent to the slave computer.
-The slave outputs the audio with a latency affected by the buffer of the slave's soundcard.
-The audio enters DP affected by the input buffer on your DP computer's soundcard.
-The audio is mixed in DP and then output. It suffers again from buffer latency this time from the output buffer.

Therefore at a buffer setting of 128, you would incur a total of 384 buffers using a slave computer. This is 200% more than if you use the VI natively in DP where you are only incurring the output buffer penalty.

You also get the benefit of delay compensation if the VI is inside DP (or if you use VE Pro on a slave computer using the VEPro MIDI channel and ethernet audio). This isn't necessarily helpful for live playing, but once the MIDI is in DP, it will be more accurate.

However the usage of a slave computer is VERY advantageous if you have very large VI templates because you almost always will be more likely to run at lower latencies combined than if you had to load everything in DP. For instance, you may be able to run at 128 in DP and on your slave in a situation where if you loaded everything in DP, you may not be able to get smooth playback until you passed a 512 buffer or higher. It depends on your system and your template size.

[Tim]

There is really only one solution, which I've recommended many many times
here - get another computer to run VI's. Get an audio/MIDI interface for that computer. Hook it up via MIDI like any hardware synth. Buss the
audio from the second computer back into DP. Presto - no latency, even
at higher buffer settings.

No latency? How? ...and how are you bussing back into DP.

The only way I know to do this is via network with the likes of VE Pro, and the 'no latency' is only on playback when ADC can be calculated.

[hommeout]

Thanks for the input guys!!

Micihch,you're the man!!
I've try your idea and raise the sample rate at 96Khz,I had absolutly no hope for this but I was like"It doesn't cost much to try it" and it work!!
I've calculate that my actual latency is now about 5ms,I basicaly cut the latency in half.
I still don't have any glitches but the CPU is working about twice much than when am at 44.1Khz.
The reason why I need to have the lowest latency possible is because I need to be able use a limiter plug-in in real time.
In my home studio,I have those amazing speakers (Duntech) that am using for main speaker,when friend come by to see me play guitar(One stereo track live and one playback stereo track),I really like how they sound but I drive them pretty much at their limit,I need something to limit the signal cause I keep blowing the tweeters.
After blowing my first tweeter,I've put a pair of analog compressor(Aphex) adjust as limiter just before the power amp in order to stop the unwanted peak.
It work for 2 weeks but I've blow another tweeter lately,I knew the Aphex could not perform a real "brickwall limiting" but I had to try.
That the reason why I need to be able to use a stereo limiter plug-in with the lowest latency possible.
The limiter plug-in that am using is Waves L2,am aware that the "look ahead" fonction may introduce some latency but that's also the key point for the "protection" that I need.
So,right now,I can playback 1 stereo track(drum,bass,synth...) and play the guitar part live,all that thru one stereo limiter plug-in and have a latency of about 5ms.
Again,am not sure if this gonna solve my problem but it worth a try.
Thanks Guys!!

[kassonica]

Wow you could just turn it down

Or put fuses in the duntechs.....

[hommeout]

The thing is,there is someting happening when the Duntech are at their limit,some "3D ness" like I've never experience before,my near field monitor are Barefoot MM27 and they are very good,very accurate monitor but still,the Duntech are in a whole other level when they are loud and if I turn down the volume,the "3D ness" go away,once you have taste this 3D holographic thing,you don't wanna go back to regular music.
So turning down the volume is my very last option.
The Duntech are my first passive pair of speaker and am not really aware of the possibility like puting a fuses,let say that am trying to find solution according to my knowledge.

[daniel.sneed]

Limiting is probably NOT the best way to achieve this.
For the musical program high frequency content is generally much lower than the middle and bass frequency content.
And the tweeter power limit (before blowing) is generally much lower than middle and bass speakers.

A limiter won't see the difference at all.
It will hard limit the whole program, in a much perceived way, OR will let enough high frequency content to blow your tweeters.

The exact answer to your question would be a multiband compressor.
AFAIK, they will induce much latency, though.

A great, but pricey, solution would be a hardware multiband compressor.
Or... different speakers!

[hommeout]

Hi Daniel

Thanks for your input.
I understand what you're saying,it might not work but in order to be sure,am gonna have
to try it and maybe sacrifice another tweeter!!(For the science)

[daniel.sneed]

Back in the years, I've used some sort of electronic pieces, which did act as a *auto-reset* fuse. They were called POLYSWITCH.
That was with PA systems tweeters, though. This happened to be a very cost-effective solution to blowing.

AFAICR, after a few unfortunate tests (!), values were 500mAmp to protect big tweeters, and 680mAmp, or 800mAmp, to protect big high frequency compression drivers.

[monkey man]

There is really only one solution, which I've recommended many many times
here - get another computer to run VI's. Get an audio/MIDI interface for that computer. Hook it up via MIDI like any hardware synth. Buss the
audio from the second computer back into DP. Presto - no latency, even
at higher buffer settings.

No latency? How? ...and how are you bussing back into DP.
The only way I know to do this is via network with the likes of VE Pro, and the 'no latency' is only on playback when ADC can be calculated.

Stumped on this one too. If I'd thought it were possible, I'd have explored this method of working rather than chosen the MIDI hardware route.

[Timeline]

Maybe he means run the VI's which are complete on the second slave mac in play with whatever latency is required then on the main computer run audio only at 64 or slightly higher... Something like that. Seems this might work. Think you would need pretty similar speed machines t really test it. I would lover to try that.