A weird latency thing happened tonight


#1

I’m using Gig Performer for a duo setup. We have a keyboards rig with layers/plugins/etc., and then a separate instance where we have the direct-in vocals and guitar. Latency-wise, keyboards and vocal mics are fine. the guitar input is experiencing significant latency, even though they are coming into the audio interface directly, same as the vocal mics. We are using an RME Fireface 800 interface, the guitar and mics are plugged into the interface, so there’s nothing different there, except the guitar is processed through iRig on an iPad. We tested just bypassing the iRig and going direct to the RME, still it has unacceptable latency. the RME buffer size is set at only 32. If I bypass GigPerformer for the guitar, there’s no latency, but if it goes through GigPerformer, the latency is there. The only difference I can see is that the guitar input is a Hi-Z input, the mics are Low-Z. What could be happening?


#2

The rme buffet is set to 32? That would not create audibke latency. It most likely cause horrible distortion as the usb drops data. Maybe you are setting the buffer in some software other than gigperformer.


#3

The RME interfaces via Firewire 800, and is connected to my MacBook Pro via an adapter to thunderbolt 3. This is very strange. I have 2 mics connected via XLR, and 1 guitar connected directly via 1/4", nothing else in the chain for it. It does not matter which channel I connect the guitar to, it has a huge latency, but the mics are fine. I only set the RME to 32 because it is the lowest setting, but it doesn’t matter what I set it to, the latency is there. So, that means 3 things going into the RME inputs, and only one of them (guitar) has latency. If I bypass GigPerformer and monitor the input coming directly out of the RME, there is no latency.

I have a gig for my keyboard patches, and an instance with a rackspace for the mics/guitar.

What is really interesting is that if I go back to my MainStage concert, there is no latency on the guitar.


#4

The buffer size of 32 is most likely too low for some plugins to cope. Not sure if it makes a difference or not, but 128 is really low. The difference between 32 and 128 in terms of that latency is about 2ms. Studies have shown that a human cannot perceive anything below 3ms.

That’s just a side note because I often hear people driving their hardware too hard for no good reason and when there’s need for a bit of CPU headroom - it isn’t there.

Back to the issue…

You’re not saying what plugins are you using with your guitar?
What happens if you bypass those plugins - do you still have latency?

btw… your audio settings will not matter one bit if you have one plugin that’s holding up the entire processing chain because it can’t cope with a live processing.


#5

Correct me if I am wrong, but I think the latency is a setting in the software NOT the hardware device. This is why you must set it in gig performer or other software accepting the audio input and why it will be different according to software used, including possibly the plugins.


#6

Latency is the delay result of the signal being generated and you hearing it. It involves absolutely everything during that process. Software rendering is just one piece of it.

If you open Window-Measure device latency in Gig Performer you will see the current software setting latency, the hardware input latency and the hardware output latency. This input/output latencies depend on your hardware and it’s driver. These are the A/D - D/A converters.
If you play a guitar or use vocals for example - you have to take the input conversion + software + output conversion into account. If you play keyboard for example - then you only need to look at software + output latency.

As I mentioned earlier - a difference of 2ms (or 2 feet approximately) should not be perceivable by a human. It if was an orchestra would never be able to play in sync - think about how far apart are players from each other.


#7

So, I spent a good deal of time today diagnosing my problem. It seems that if you have multiple inputs, some with plugins, some without, that GigPerformer “syncs” the inputs, so if some have plugins that cause latency, then even the direct tracks without plugins (in this case, the guitar), will also be latent. I removed the vocal plugins, and there was no perceived latency on any of the inputs, then one by one added different plugins to the vocal inputs that accomplished the same goal, and now the perceived latency with the guitar input is gone. I did initially experiment with different buffer sizes on the audio interface, and could not get rid of the guitar latency, but now that I took the other route I’m in good shape.


#8

That makes sense. Thanks for posting back.


#9

Yes, if you think about it, audio data can only get through as fast as the slowest plugin since the audio of all plugins has to be merged together.


#10

I have difficulties to follow… if GP synchronizes every audio data based on the slowest plugin, all audio data should have a similar latency and the guitar shouldn’t have an extra delay, no?


#11

I don’t think it was just the guitar. It was the entire setup and, as @dhj mentioned - if you insert a vocal plugin that does pitch correction for example - it may delay the entire rackspace. iZotope’s Nectar for example has two modes - one for mixing and one for “tracking” which is capable of working properly in live environment.


#12

@djogon - So, I suppose the first GP instance with the keyboard was not delayed, and the second GP with the guitar was. But, a delay is probably more noticeable when playing the guitar than when singing. Right?

@stansongman - By the way, what is the plugin applied to the voice that caused the latency?


#13

If you use two instances they work independently.


#14

OK, that’s what I understood. So, in the present situation, the idea could be to put the processing of the voice in an individual instance, because the latency doesn’t seem to be noticeable on the voice, and so the guitar wouldn’t have any additionnal latency.


#15

Yes - that would be a good plan