I got some situation here… stuck with a weird phase/latency issue seemingly introduced by GP itself.
I’m building an fx rack where most of the processing happens in global rackspace.
Still I want to be able to add song-specific extra fx in local rackspace.
The basic chain looks like this:
[global] audio in, preamp chain
[global] global fx
[global] send to local
[local] (add extra fx if needed)
[local] send back to global
[global] dry/wet mixer
[global] apply master fx and send to audio out
I’m stuck at the “dry/wet mixer” step.
Dry signal comes from preamp step, and when setting the mixer to 50:50 I noticed huge phase issues.
I can safely state that this is no latency introduced by a plugin:
using pre-local-rackspace wet signal → no phase/delay issues
using post-local-rackspace wet signal → phase/delay issues (local rackspace is connected to send back immediately, no blocks in between.)
So I did a multitrack recording and compared the tracks in my DAW.
Turns out that the audio sent to local rack and back is delayed by ~28 ms
I’m out of ideas. What is happening??
Aside from the phase issues… that’s just way too much latency to be useable.
Hover over each of your plugins and note which ones show a “Latency” value in the tooltip.
Uploading an example gig file will help us to test and/or replicate the routing you have.
I did some more investigation and I think to understand what is happening - at least partially.
It comes down to confusion on how GPs latency and latency compensation is working.
I observed following behaviors:
bypassed plugins add to latency
plugins that have no connection to audio i/o add to latency nontheless
Regarding global+local rackspaces it seems that
sending audio back and forth between local and global rackspace adds SOME latency (need to do further measurements)
which means mixing (= combining into one signal) audio from local and global rack does not work as one signal has more latency.
I’ll try to find out some more and maybe provide some example projects if there is any meaningful to show.
I think it would be a great addition for in-depth documentation to describe how latency management of plugins and in between global and local racks is working.
@dhj I’ve built a setup and ran some tests.
As soon as routing in between rackspaces, I found some hugely irritating behavior.
Please see attached image for detail on what I was able to find out.
My OS / Audio settings: Windows 10 22H2 / GP 4.8.2 / 128 Buffer size @ 48 kHz.
I was able to reproduce the issue with multiple vsts, one of them being freeware (Voxengo Latencydelay).
I’m confused as to why you would be using Voxengo Latency Delay to test this latency issue. That plugin works by automatically adding 10000 samples of latency that you then dial down. In your gig file, you have those plugins set up with the full 10000 samples of latency, so of course there will be an audible delay in the signals that pass through them.
I do use this plugin, and like I said, you use the dials to subtract from 10000 to achieve a desired latency. Go ahead and max each of the dials in the (samples) section to 9 and you’ll hear how the latency disappears.
@edm11 + @dhj
I used Voxengo Latencydelay first and foremost because it is freeware and I needed an alternative to Pro-G to share a project with you so that you can check/reproduce.
I’m 99.9% sure this behavior can be reproduced with any plugin that delays the audio by X and reports so to the host.
I’m absolutely clear about GP being a real time application where latency compensation is impossible.
But while it cannot work with negative latency compensation, it will keep routes with different latencies in sync by delaying audio to stay in sync with the slowest route. (=> Comparing (1) and (2) we can see that GP adds a delay to (1) to keep it in sync with (2) as the plugin reports a 10ms latency.)
The test suite shows inconsistencies on how GP handles reported latencies, resulting in unexpected behavior and latency issues:
As soon as a route goes into a different rackspace the results become unpredictable.
If the to-rackspace-and-back loop is removed, GP will add correct delays and all recorded tracks are in parallel again.
If this is intended behavior… please explain what is happening here. How can (4) and (6) of test 3 have less latency than (3) and (5)? To me it looks alot like a bug in latency delay calculation.
Well, if intended, let’s document it and write down best practices and routes that must be avoided to not run into latency/phase issues.
And if it is not intended behavior… maybe we can find out what is happing and how to improve.
I replaced the to-local-rackspace-and-back loop by a gain block and… no more issues,
all recorded tracks are synchronous again.
So when crossing borders of local/global rackspace, either GPs route latency compensation fails or it behaves in an unintuitive way. Then I suggest to document the how&why of this.
I understand what you’re trying to get across and I was able to replicate a version of it.
From what I can see, whatever latency compensation occurs in GP only occurs in a per-rackspace capacity. Once a signal crosses into another rackspace, (from a global to a local, or vice versa), there is no longer any compensation occurring. It can be demonstrated simply like this, with one channel going straight from Audio IN to Audio Out, and the second channel running through a plugin with added latency, out to another rackspace, and then to the Audio Out:
The channels will be out of sync and the delay will be audible, whereas if, instead of connecting the second channel to the other rackspace, you connect it directly from the plugin to the Audio Out, GP compensates for the latency and both channels are in-sync.
I guess what this means for you is that you’ll have to adjust your rackspace builds and routing to ensure that final audio out signals that are meant to be in-sync are being received from the same rackspace. Fortunately, GP gives you many different ways to solve most problems.
Interestingly enough, I’ve also found that if you use my first example above, and you also connect the plugin directly to the Audio Out, GP compensates the entire signal chain from both rackspaces. It does of course add gain from the added signal. That would have to be sorted out, but it does give you a way to use your original routing without the out-of-sync discrepancies.
EDIT: You can solve the added gain issue by putting a Gain plugin in between the plugin and the Audio Out, and muting it. Interesting.
I noticed a similar issue, but to simplify even further,
I have noticeable latency when I’m running audio through global Rackspace in comparison to a local backspace.
So much that it’s not playable. (I didn’t measure, but I’d estimate over 25ms)
I’m looking to build a rig where I can use my Nord stage for audio and turn it off or on depending on the patch and the mix of VST that I am using.
The plan was to run the north through the global
Rackspace so it’s always an option to turn on or off, And then run additional soft soft synths in local rack space.
I run audio in through the Global rackspace, send to local rackspace, and then back out through the Global rackspace with no latency issues, so there must be something else going on with your setup.
I do have other plug-ins (Not in the test signal chain) in the global Rackspace, On second thought that would actually add latency to the entire global workspace, correct?
), what OS are you using, what audio interface and driver, and what sample rate/buffer size are you using?