An audio performance/ASIO mystery…

Hi, all

I would be delighted to see a rational explanation of what follows. It’s not critical and doesn’t prevent me from using Cubase, but still… I like to understand what’s going on under the hood and, in this case, I truely have a problem.

FWIW, here is my setup configuration :

  • AMD Ryzen 7 3700X with an Asus Prime X470-Pro motherboard (32 Gb DDR4).
  • 2 SSDs (WD black M2, 500 Gb + Corsair Force MP300 1 Tb)
  • AMD Sapphire Radeon RX550 (2 Gb) + AOC 32" monitor @2560x1440 (scaling : 100%)
  • RME Fireface UCX (USB) + Behringer ADA-8200 ADAT extension (connected via 2 TOSLink cables)
  • Windows Pro 10 (22H2) + Cubase Pro 12.0.60

This morning, I set up a minimal project with only the sources/tracks I am using the most, importing them from a pre-existing one with the File > Import > Tracks from project command. At this point, of course, the project is brand new : neither a record or media import has been done nor any automation defined. So, while testing it, I saw that for a reason, the audio performance was jumping from something like 6-8% to more than 25% simply by activating the Monitor button of a track which receives a condenser mic signal, and this wasn’t happening with the 4 other audio tracks.

So, as a test, I removed the involved track and made another one with the same input/output routing and activated Monitor : no issue. Going further, I added the two sends to FX reverbs (REVelation and Acon Digital Verberate Basic 2) that I was using in the track removed and activated them : the Peak jumped as previously, trebling its value, when I activated the The Acon send. Strangely, the REVelation one is not affected : no peak value jump of any kind.

Testing further, I realized that all the audio tracks were actually acting the same way : as soon as both the Monitor and the Acon send are activated, the Audio performance|Peak value goes immediatly three times its ‘normal’ value. And there is more : in all cases, after deactivating the involved send, it takes exactly 13 seconds to the Audio performance|Peak value to suddenly go down to the ‘normal’ 6-8% value, no matter the audio track involved. Beside this, when deactivating Monitor, it goes down to the same value immediately, no matter if the Acon send is active or not.

At this point, I tested this on the different instrument tracks I had at disposal, using their audio send slots. Absolutely no issue with them, no matter the track used, the send activated or the Monitor state : the peak value remains at 6-8%.


So, and to sum up all this, my three questions :

  • How comes that, simply by activating a send, the Audio performance trebles its value, as the plug-in is already loaded and functional ?
  • Assuming that the issue reveals an Acon Verberate plug-in flaw, why only the audio tracks are affected by this behavior ?
  • How comes that this occurs only when the Monitor setting is On ? I get that there is added processes in the signal chain in this case, but the plug-in is already loaded and active.

Thanks for any enlightment… :slightly_smiling_face:

Monitor button switches the signal flow to real time audio. It needs to work with low latency and stresses the system more than normal.

1 Like

OK, it’s logical. But how to explain that, as the Monitor is already active, just activating a send trebles the Peak value, as the FX plug-in is already loaded and functional ?

The key phrase in st10ss’s (:slight_smile: ) post is “real time”. It’s not that the plugins are instantiated, it’s that they move to be included in a real time path. In the manual it says "Peak
Shows the processing load in the real-time path of the audio engine. The higher this value, the higher the risk that dropouts occur."

And if you think about it that’s pretty reasonable. You can have more lag using the buffer when things aren’t running in real time, but once you need real time processing the CPU has to process everything, well, “real time”. So the load on the CPU goes up.

Why does it not go up when the send is not activated? Because if the send is ‘off’ then there is no audio flowing into that path in real time. Why does it not go up when monitoring is switched off? Same thing.

As for the instrument track I would assume that it has to do with the fact that it’s not an audio input path that you’re monitoring.

1 Like

This is where I have a problem : even if there is no audio flow, the plug-in remains active and ready to receive any signal, I guess, unless ther is some hidden and magical switch that detects any audio signal flow interruption. I know that there is the Suspend VST3 plug-in processing when no audio signals are received setting, but still… I had issues using this one in the past, so I keep it unticked. Maybe I shouldn’t…

Beside this, and concerning the instrument track, no, it’s not an audio input, but at the end it’s an audio result hearable in the Main output bus. So…

I was wondering about the instrument track, too, but from my tests I am pretty sure that enabling “monitor” on an instrument track does put it in the real time path (as does “record enable”), else you would have a really high latency from ASIOGuard when playing some notes through it. Also, the real time value in the performance meter jumps the same amount when enabling “monitor” or “record” on a CPU intensive synth track.
I am not sure why enabling the Verberate send wouldn’t register on the performance meter for you, it does here on my system, especially with “Suspend VST3 processing” disabled. With that option enabled, it is a bit different, it jumps a bit higher when playing notes, but falls back after a time of silence (which tells me that Verberate does honor the “disable VST3 processing” - which is a feature that plugins have to actively support). On the audio track, real time load stays high, logically, because there is always a signal coming from the mic preamp.

Verberate btw is much more CPU intensive than Revelation, which explains why you don’t see anything on the meter with just the latter enabled.

1 Like

Hi, @fese

I’m rather lost, at this point. The main concern I have on the subject is this one : as the monitor is already active, why simply activating a send (the Verberate one) in an audio track makes the peak meter jump to three times its initial value, as the plug-in is already loaded and functional ? I perfectly get that enabling Monitor puts the involved track in a ‘real time’ processing. What i don’t get are :

  • the difference between audio and instrument track behavior as, at the end, it’s an audio result that we have in Main out bus,
  • why does the Audio performance load is trebled simply by activating a send, as the FX plug-in is already loaded and functional, this, with the Monitor already active.

So yes, playing the VSTi of an instrument track will increase the Peak value. I remember, something like 15 years ago (Cubase 4 days…), having changed the E6700 processor I had for a Q6700 one, because of this : using a sustain pedal with a piano VSTi almost instantly led to audio glitches, as the processor wasn’t able to cope with it. The change solved the issue. At least, we are now in better days where processors are able to process these kind of things.

This said, I acknowledge that the Verberate is CPU intensive : too bad, as I really like the sounds I’m getting from it. But, IMO, it doesn’t fully explain the completely different behavior between it and the REVelation one, placed in the same way in an audio siçgnal path.

I think we gave a plausible answer to this already. It’s not about just instantiating and activating a plugin, it’s if it’s used. If you have a send that goes to it but the send is turned off then there is no input to that plugin. With no input it won’t be in a realtime signal path because there’s no signal to process. Once you turn the send on there’s now an actual path created and if you have the source set to input monitor it seems logical that the connected track would be realtime as well.

I think the send destination also has other sources, i.e. other audio tracks not monitor enabled.

As soon as an audio track is monitor enabled, all the path the audio track goes must be switched to realtime. E.g. you have a delay on an FX send of the audio track, by enabling the monitor on the audio track, the delay will be switched to realtime, I think you get this.
Then if you have another track that goes to the delay line, this track has to be switched to realtime, because the delay line is now realtime.

So in your case, you can duplicate the send destination, re-route the monitored audio track to the newly created one. This will reduce the peak meter drastically.

1 Like

But IT IS USED ! It’s a send (IOW, it behaves as a bus), from which, it receives signals from different audio or instrument tracks already set. It’s THIS that I don’t get… :thinking:

If it’s not activated it’s not used. You wrote peak jumped when you activated a send.

Just re-read the whole thread. Not sure if I can explain what I mean any more clearly.

This is the reason. All the tracks sent to the send destination becomes realtime when you mix it with realtime audio.

2 Likes

I activated a send for a given audio track. For the others, mainly the instrument ones, the sends to the Verberate FX track were already activated. What more to say ? maybe it’s a Acon Verberate flaw…

Were those other tracks also set to monitor input?

No, I don’t remember having set them as so. You are probably right on that one.

More test is needed on my end, I guess… :slightly_smiling_face:

Makes sense, thanks. Still, does it explain such an ASIO load difference, using two FX as sends in a similar manner ?

It’s not necessary to calculate pre-recorded tracks when sent to an FX send mixed with a realtime track, like the master itself. If everything mixed with realtime track must be realtime, then all routed to master should be realtime and we know that’s not happening.

But AFAIK, when I checked this some years ago, Cubendo behaved this way as I described. If you send non realtime tracks and realtime to one destination, all become realtime.
So again, try duplicating the FX track, re-route the monitor ready treack the FX, I bet you get a much lower peak, even with the duplicated extra plugins.

2 Likes

Haven’t thought of this, I admit. i’ll try this ASAP. Thanks ! :slightly_smiling_face:


EDIT - FWIW, I just made the test. It’s indeed a little better, but marginally. The problem is that the peak metering is really unstable, so it’s difficult to say if there is a change worth keeping this setup or not.

Thanks for the help, @TakashiWatanabe :slightly_smiling_face:

Don’t worry about the Peak meter, even if it goes to 100% you won’t necessarily have dropouts.
From my experience dropouts only occur when the Real Time meter maxes out, although the two meters are linked and they generally move in relation to the other. The Peak is always higher because it shows the actual CPU processing peak, so even if the CPU’s processing capabilities (for your current buffer settings) maxes out for a few samples in duration, it will go to 100% and turns red, but you won’t have any dropout as long as there is enough headroom to process all the samples. The Real Time meter on the other hand is calculated over the buffer period, so if this one turns red it’s because it couldn’t process all the samples in time, and you’ll have a dropout.

Mysteries will always be mysteries… just don’t worry with that one. :slightly_smiling_face:

BTW I can’t seem to replicate the “issue”. I have tried with the same routing as yours and when I enable Monitor both Real Time and Peak increase, just as usual, unlike on your images where only Peak increases.

3 Likes

Yep, I probably over-reacted on that one. I wasn’t used to see the peak meter jumping like that, so I’ve been concerned about what was going on. And as long as the project is usable…

About your replicate, it could show that there is a problem on my end. Will look at this further and post here again if I find something.

Thanks for your concern, Louis… :slightly_smiling_face: