Latency bug with Item FX blend (NOT FIXED)

[MRMJP]

I'm not sure if this is a REAPER bug or a Goodhertz plugin bug but I found a case where sometimes on play/record there is a latency issue that is noticeable when the plugin blend is set below 100% and over 0% of course, and most noticeable when set to 50%.

Check this video:
https://dl.dropboxusercontent.com/u/...GHz_PDC_V1.mov

Excuse the poor audio quality but Quicktime only captures mono audio and this is already at a loud/mastered level so the recorded video audio is distorted and bad. But, you can hear that when I change the blend to 50% that there is a some bad latency/flanging/flamming etc.

I can't reproduce on every record/playback but it happens often. I hope this isn't happening on all item FX that are set below 100% and only most noticeable on this one because it has a very high latency.

Here is my current REAPER config:
https://www.dropbox.com/s/16qxej6kiq...ConfigZip?dl=0

Here is the session sans audio so you can see what I'm doing:
https://www.dropbox.com/s/pyurc8bl8g...pture.RPP?dl=0

I'm basally sending a track with items and item FX out to two hardware stereo outs and capturing back in on a new track.

This has been working well for awhile but maybe I've never blended the Goodhertz Tone Control plugin before using the native REAPER FX blend.

I will contact Goodhertz too but wanted to post here incase it's a REAPER issue as I've seen a very similar issue occur when trying to use the plugin pins to duplicate a stereo feed to another hardware output. When FX are blended below 100% I would sometimes get this issue.

[goodhertz]

Thanks for the post, Justin.

What does REAPER report for you for Tone Control's latency in HQ mode? It definitely seems like REAPER is not accounting for the latency with its built-in blend. One other possibility: the latency of Tone Control changes when the HQ mode is activated, so it's possible that REAPER isn't picking up on this latency change. That said, I know it works properly in other hosts.

Aside from the bug, is there any specific reason you're not using Tone Control's built-in master mix control? It should act similarly but is guaranteed to be phase coherent.

[MRMJP]

Originally Posted by goodhertz

Thanks for the post, Justin.

What does REAPER report for you for Tone Control's latency in HQ mode? It definitely seems like REAPER is not accounting for the latency with its built-in blend. One other possibility: the latency of Tone Control changes when the HQ mode is activated, so it's possible that REAPER isn't picking up on this latency change. That said, I know it works properly in other hosts.

Aside from the bug, is there any specific reason you're not using Tone Control's built-in master mix control? It should act similarly but is guaranteed to be phase coherent.

Thanks Devin. I'm getting 4096 samples of reported latency @ 96k from Tone Control in HQ mode. You're right that I should have been using the built-in mix control of the plugin but honestly, I forget it had that option as I'm so used to used the native REAPER FX blend which is one of the great features of REAPER in my opinion.

Anyway, I mostly want to get to the bottom of why this happens incase it also affects other plugins in a way that is harder to detect. Maybe being at or near the end of the item FX chain, this was the plugin that pushed REAPER over the edge of item FX latency support.

What's weird is that it only seems to happen on SOME playbacks but not all the time. I didn't notice this when I was working and stopping and starting the transport in the middle of items.

BUT, when I went to play the entire session through from start to end in one pass and print it to the new track, this is when problems occurred.

I wonder if there is an issue initializing PDC on items when playing the entire session through as opposed to a hard start and stop within an item? I seem to get random results when I play from the start vs. starting in the middle of an item that contains item FX.

As I said, I had a VERY similar issue to this when I was trying to use plugin pin connectors on the first inserted item FX to mirror the stereo feed to another hardware output. It worked great EXCEPT when I started using the item FX blend knobs. Then I would start to get these kinds of issues so I stopped doing that.

I'm hoping Justin or somebody from REAPER can take a very close look at this to see where the problem lies.

[Justin]

I can't duplicate this with 5.29, using TC2X on both item and tracks, with HQ mode (2048 samples latency at 48khz), REAPER's wet/dry at around 65%.

I have the gains at +0dB, then I compare the output of that track to an unprocessed track, and they null every time. If you have a way to duplicate I'd be happy to take a look.

[MRMJP]

Originally Posted by Justin

I can't duplicate this with 5.29, using TC2X on both item and tracks, with HQ mode (2048 samples latency at 48khz), REAPER's wet/dry at around 65%.

I have the gains at +0dB, then I compare the output of that track to an unprocessed track, and they null every time. If you have a way to duplicate I'd be happy to take a look.

Thanks Justin,

I'll try to find a reproducible way later today. Did you check my actual session I linked to? A few of the items have TC2X inserted. I wonder if it's just high latency in general that causes this. I may not be related to this plugin but just general hight latency.

Like I said, it wasn't every playback but it happened often. Most noticeably when playing from well before the item starts. It seems there is a problem with the PDC engaging properly when the FX blend knob is used as a new item starts.

[MRMJP]

Originally Posted by Justin

I can't duplicate this with 5.29, using TC2X on both item and tracks, with HQ mode (2048 samples latency at 48khz), REAPER's wet/dry at around 65%.

I have the gains at +0dB, then I compare the output of that track to an unprocessed track, and they null every time. If you have a way to duplicate I'd be happy to take a look.

I also wonder if having another track in the session in record arm mode has any influence on this behavior. With my workflow, I always have a track armed so I can monitor the analog input, and then of course I record it. So, perhaps record arm/monitor or actual recording has an influence?

[MRMJP]

Originally Posted by Justin

I can't duplicate this with 5.29, using TC2X on both item and tracks, with HQ mode (2048 samples latency at 48khz), REAPER's wet/dry at around 65%.

I have the gains at +0dB, then I compare the output of that track to an unprocessed track, and they null every time. If you have a way to duplicate I'd be happy to take a look.

@Justin,

I tried recreating this issue in a more simple session but I could not. It would mean a lot and put my mind at ease if you were able to check out the session I posted and also confirm you see/hear the issue in my video clip.

I really need to be sure this isn't happening to a less noticeable degree in any future session.

[MRMJP]

Originally Posted by Justin

I can't duplicate this with 5.29, using TC2X on both item and tracks, with HQ mode (2048 samples latency at 48khz), REAPER's wet/dry at around 65%.

I have the gains at +0dB, then I compare the output of that track to an unprocessed track, and they null every time. If you have a way to duplicate I'd be happy to take a look.

What I've found as I dig deeper is that @ 96k, the Tone Control plugin has a reported latency of 4096 samples when the HQ mode in the plugin is engaged.

What I can report is that sometimes even with HQ mode engaged, REAPER thinks there are 0 samples of latency and that's why there is an issue when the blend knob is used.

It doesn't always happen, but sometimes what happens is when I start playback from before the item, the reported latency is wrong once the item is being played.

Is this a REAPER issue or plugin issue?

I have a video capture of it but don't want to share it publicly because it contains a client's music. I can share privately if interested.

[MRMJP]

Another thing I notice is that with something like Zero Crossing Maximizer plugin, when you change the buffer size during playback, REAPER is pretty quick to recover and recalculate the latency on the fly and adjust so everything is in sync again when the FX blend knob is used.

With Goodhertz Tone Control, if you turn the HQ setting on or off during playback, the reported latency isn't updated until playback stopped and started again.

I'm guessing this is related to the issue I'm seeing but the question is why it's only on some playback instances that the latency is incorrectly reported and then there is this issue when the FX blend knob is used.

The short term solution is to simply use the blend knob within the plugin but I want to be certain this isn't happening with other plugins that may have a much less obvious latency that is more of a comb filter as opposed to the slapback sound you get with longer latencies.

[Ollie]

REAPER is re-calculating PDC on playback start only, so you need to stop REAPER before any parameter changes that affect plug-in latency can be taken into account. I don't know of any other reports about PDC inconsistency during playback so far, and the latency-introducing plug-ins I tried as take FX didn't show anything unusual with dry/wet mix at 50%. So I think the issue is restricted to the Goodhertz plug-in.

[MRMJP]

Originally Posted by Ollie

REAPER is re-calculating PDC on playback start only, so you need to stop REAPER before any parameter changes that affect plug-in latency can be taken into account. I don't know of any other reports about PDC inconsistency during playback so far, and the latency-introducing plug-ins I tried as take FX didn't show anything unusual with dry/wet mix at 50%. So I think the issue is restricted to the Goodhertz plug-in.

This is interesting. These must be times on playback start when the Goodhertz plugin does not report the latency and then when the play cursor gets to the item, the processed sound is late which is especially noticeable when using the FX blend knob.

From now on I'll use the internal mix knob the plugin but I mostly wanted to make sure REAPER wasn't doing this with other plugins too but it does seem like a Goodhertz fix.

[Justin]

AU dynamic PDC support coming soon!

[MRMJP]

Originally Posted by Justin

AU dynamic PDC support coming soon!

Awesome, thanks!

Will this have any affect on UAD plugins? When it comes to item FX, the AU versions tax the UAD DSP all the time even if the item is not playing or even if the transport is not even playing at all. The VST versions of UAD only tax the UAD DSP if that item is playing.

It would be nice to see the AU versions behave like the VST versions.

[Justin]

Originally Posted by MRMJP

Awesome, thanks!

Will this have any affect on UAD plugins? When it comes to item FX, the AU versions tax the UAD DSP all the time even if the item is not playing or even if the transport is not even playing at all. The VST versions of UAD only tax the UAD DSP if that item is playing.

It would be nice to see the AU versions behave like the VST versions.

I'd just use the VST versions.

[MRMJP]

Originally Posted by Justin

I'd just use the VST versions.

I thought about that and tried that but it seems that if you have a mix of AU and VST plugins on an item, when you move between the GUIs of the items plugins during playback there is a slight disruption. When you have all AU plugins, the playback is smooth when you move between plugin GUIs during playback.

I'm not sure if it's an issue of mixing AU and VST, or if it's a VST thing but it's not ideal.

I tried moving to all VST plugins instead of AU but I ran into that issue where FabFIlter (and maybe some others) don't always remember the settings and presets unless audio is passed through the plugin.

[MRMJP]

Originally Posted by Justin

I'd just use the VST versions.

I just tried a session and used the VST version of UAD Ampex ATR-102 instead of the AU version. When I inserted an AU plugin after the UAD plugin while playback was happening, there was still a latency issue that I pinpointed to the UAD plugin as it was blended to roughly 70%.

So far, a stop and start of playback fixed it. I gave it about 20 seconds to dynamically adjust the latency itself but no luck.

If you could look into the FX blend when latency is involved that'd be great. It would be s shame to print something with a less noticeable issue. Luckily the UAD is so late that is sounds like obvious slapjack, whereas some latency is more of flange/phasey sound.

FWIW, this is with Item FX. I can't speak for track/channel FX as I don't use them.

[MRMJP]

Something is still not right. Even when all AU plugins are used, if i insert a plugin during playback (with another track in record monitor to hear audio coming back from the analog gear) there can sometimes be that phasey/metallic/weird sound when FX earlier in the chain are set to less than 100%.

The Dynamic AU PDC that was added doesn't seem to work. I often give REAPER 10 or 15 seconds to adjust but it never does. The only thing that works is to stop and restart the transport.

Also, yesterday I accidentally used a VST instance of a UAD plugin when the rest of the plugins on that item were AU. When I went to actually record the audio back to a new track which I do in one pass...of the 9 items on the timeline, the only one that had an issue was the one with the mixed AU and VST FX. For whatever reason, the PDC was not correct when it came time to play that item and the printed audio to the new track had that phasey/metallic/weird sound because some FX were blended to less than 100%. I ended up converting to all AU and reprinted that song.

[MRMJP]

I can still reproduce cases where on playback, the FX blend causes a phase problem. Not often but now and then I'll move the cursor to play an item and there is a clear problem. The dynamic PDC never catches up.

The only thing that fixes it is stopping and restarting playback. I'm using all AU plugins on the item when this happens.

It would be nice if one of the devs could take another look at this and weigh in.

One special note is that on the track this item is on, I'm sending it to 3 different hardware outputs and monitoring the input on a new track armed for recording while I make my plugin and hardware adjustments.

[MRMJP]

Still happening with 5.35

Certain AU plugins such as UAD and Brainworx (and probably more) have latency issues when the FX blend is used on an item FX.

Usually stopping and restarting playback fixes it but it would be nice if it never happened. Especially because it can happen for me on a random basis on some playbacks as items start and end.

A user in another thread had a 100% reproducible case that may be related.

[MikComposer]

Finally some who has noticed this! This issue exists since reaper 4!!!!!!!!!

Try Vintage Exciter for example, it will create an awe full phased sound!

And I wasted so much time and life because of little shitty issues like this! It literally took me years to understand it is not me whos doing this.

Thanks reaper.

[JamesPeters]

Any plugin with latency can potentially cause this. If you're using Reaper's own wet/dry blend control, the plugin's output has to be in phase with the dry signal otherwise phase cancellation can happen. So if the latency isn't reported correctly (even slightly off), this can happen. Changing settings in a plugin (including during playback) can change the latency and Reaper only checks for plugin delay compensation on playback start (as already mentioned), so you can be caught off guard sometimes by changing the latency of the plugin without even realizing it. And sometimes the plugin doesn't report the correct latency to the host, so it's not always the host's fault.

If a plugin has its own wet/dry control, it's best to use that instead. Its wet/dry balance at its output, controlled by the plugin itself, should always be in phase.

If the plugin has zero latency, it shouldn't be a problem either way. I try to stick to plugins with zero latency as much as possible and I'd recommend the same thing to anyone else. Most times if a plugin has latency, there's another plugin somewhere that can do a similar job (or the same job) with zero latency.

[MikComposer]

Originally Posted by JamesPeters

Any plugin with latency can potentially cause this. If you're using Reaper's own wet/dry blend control, the plugin's output has to be in phase with the dry signal otherwise phase cancellation can happen. So if the latency isn't reported correctly (even slightly off), this can happen. Changing settings in a plugin (including during playback) can change the latency and Reaper only checks for plugin delay compensation on playback start (as already mentioned), so you can be caught off guard sometimes by changing the latency of the plugin without even realizing it. And sometimes the plugin doesn't report the correct latency to the host, so it's not always the host's fault.

If a plugin has its own wet/dry control, it's best to use that instead. Its wet/dry balance at its output, controlled by the plugin itself, should always be in phase.

If the plugin has zero latency, it shouldn't be a problem either way. I try to stick to plugins with zero latency as much as possible and I'd recommend the same thing to anyone else. Most times if a plugin has latency, there's another plugin somewhere that can do a similar job (or the same job) with zero latency.

I noticed it long time ago that when I produce, change plugin parameters, it sound different on next playback. It's horrendous. uirks like that should have own sticky thread, so newcomers would know in advance, instead of wasting years and believing like that it is their fault.

[JamesPeters]

Originally Posted by MikComposer

I noticed it long time ago that when I produce, change plugin parameters, it sound different on next playback. It's horrendous. uirks like that should have own sticky thread, so newcomers would know in advance, instead of wasting years and believing like that it is their fault.

I agree it's a good thing for beginners to know. I think it goes in hand along with getting audio devices set up for low latency use. We take things like this for granted if we understand about them, but they can mess with people when they don't.