I’m a new Wavelab user. While using an EQ plug in I noticed a little response lag. For example, when scanning with the frequency button, the audio is a bit behind so I have to pause to make sure that I am hearing the correct frequency. Also the buttons take a second to activate. Any clues?
EDIT - After reading a few posts regarding plug in delay in wavelab, I lowered the buffer size to 256 and the plug in response improved. I usually run my DAW at 1024. This was not an issue in Studio One V3. Clearly an issue in Wavelab.
Bob99,
The plug in is Brainworx BX digital V3
Windows 7 64bit
Wavelab 9.0.35
Interface buffer 1024, WL buffer 16
Yes, I can hear the lag with a Steinberg plugin - Studio EQ
I hear what you’re talking about using high buffer settings and scanning frequencies quickly with the Steinberg Studio EQ. There’s about a 1 second audible delay with 2048 and 32. Are you saying Studio One compensates so your movements and the audio you hear are always in sync, no matter what the buffer settings in the program and the interface?
I suspect you will hear a lag with no plugins inserted. If so, this could be an ASIO and soundcard/interface issue or setting. It is possible to experience this lag in WL (and other DAWs) and not Studio 1. This is because of the way Stud*o 1 handles playback … it will play back at a default rate unless you tell it not to … giving the impression of “no delay” because it does not have to send a message to your soundcard. I am no ASIO expert but it could well be more noticeable with certain soundcards and interfaces.
Also, do you have another DAW open at the same time as WL? This could also possibly impact.
Thanks Rat. No other DAW open. In Wavelab, even with 2048 on interface and 32 in program buffers, I don’t hear a delay starting and stopping playback, with or without the plugin inserted.
But I hear the delay when changing the parameters on the plugin, like dragging very quickly a 20db attenuation from 10k to 100hz, it takes about 1 second to hear the change with those buffer settings.
The plugin parameter delay doesn’t happen with large buffer sizes in Cubase or Reaper either, so would seem to be something about Wavelab. Tested with FabFilter ProQ2. RME, Lynx, and M-Audio interfaces.
Maybe anyone who scans frequency cuts and boosts in Wavelab uses smaller buffer sizes or has gotten used to the delay, because it’s the same at least as far back as Wavelab 7.
Reducing the number of buffers in the Wavelab preferences makes a difference, but the other programs don’t seem to have a delay at all, no matter what the buffers are changed to, as if they’re compensating somehow and Wavelab isn’t? Or are the buffers in the Wavelab preferences just quite long? It doesn’t make sense to me.
Each buffer increases the latency by an ASIO block size.
I will see what can be improved in a future version, about parameter change latency compensation.
Thanks PG, it would be great if you could improve it, but I have a dumb question:
Is the ASIO block size the setting on the interface? So if you have it set for 1024 samples, that’s the ASIO block size? Which would be about 24ms at 44.1? Then that’s multiplied by 4 if you use the minimum setting of 4 in Wavelab? Giving you a delay of about 100ms?
That’s what seems to be said in the Wavelab section of this article:
If that’s the case then it seems you could easily get a 1.5 second delay if you use the settings I was talking about earlier (Buffer Number 32 in Wavelab, and 2048 samples in the interface).
So the delay would be expected (?) and not unheard of in a Mastering program where the latency is supposedly not as important, as opposed to the other programs that are not Mastering programs (except the Studio One mastering section), where latency is more important.
Do I have any of that right?
And the Buffer Number in Wavelab can have greater effect than the samples setting in the interface because it’s acting as a multiplier?
Is the ASIO block size the setting on the interface? So if you have it set for 1024 samples, that’s the ASIO block size? Which would be about 24ms at 44.1? Then that’s multiplied by 4 if you use the minimum setting of 4 in Wavelab? Giving you a delay of about 100ms?
Right.
If that’s the case then it seems you could easily get a 1.5 second delay if you use the settings I was talking about earlier (Buffer Number 32 in Wavelab, and 2048 samples in the interface).
These kind of extreme settings are normally never used. Extreme settings are to be used for very slow computers.
Small latencies, on another hand, are not recommended. Because the smaller an audio block, the more “travels” are to be done from the source to the output. Each travel is adding a small overhead.
And higher sampling rates? I’ve needed to use pretty extreme settings when using 192Khz with a lot of plugins. Since the block size covers shorter time periods? But I don’t normally use such extreme settings. It was just to test this particular thing with the plugin parameters.
With 44.1Khz I heard the 1.5 second delay when adjusting the plugin parameters with 32 buffers and 2048 sample block size (32 x ~48ms = 1536 ms), and that makes sense to me. What I don’t understand is why I don’t hear that same delay when simply starting playback with those same settings at 44.1. Playback starts instantly or maybe within 25-50ms. Why is that?
And higher sampling rates? I’ve needed to use pretty extreme settings when using 192Khz with a lot of plugins. Since the block size covers shorter time periods?
Yes, the millisecond become shorter.
With 44.1Khz I heard the 1.5 second delay when adjusting the plugin parameters with 32 buffers and 2048 sample block size. What I don’t understand is why I don’t hear that same delay when simply starting playback with those same settings at 44.1. Playback starts instantly or maybe within 25-50ms. Why is that?
The latency we spoke about, is 0 for playback, because the sample are loaded in advance.
The latency you experience, is because you manually change a parameter. When you do this, there are already many samples that were collected in advance, and that “ask” to be played before.