[Solved] VST delay handling broken/nonexisting in Audacity!

[Gunnar]

By the way, testing in 2.0.6 on Windows 7, almost every time I increase the buffer size with compensation off, executing your plug-in crashes Audacity. When I restart Audacity, the plug-in does not crash at the same settings that crashed before.

This should be fixed now. Link in first post has been updated to the new version.

I tested all "Buffer Size" values of 2^n between 64 and 1048576 (without restarting Audacity) and they all seemed to work fine

(Below 64 it took ages for my standard test sample, so I didn't test. But I think it would have worked just as well)

[Robert J. H.]

Your Vst plug-in introduces some nasty clicks in the audio (on windows 7 at least).
- Default settings
- Audacity 2.0.6a
- with music or chirp tone
- 44100 Hz
- buffer 8192
- compensation on

I think you should give some more descriptive names for the sliders i.e. write them out--meant for text only Gui and screen reader.
Where has the boundary setting gone to?
You could also include the Readme.htm file in the archive, this would somewhat facilitate the test usage of your plug-in.

[Gunnar]

Your Vst plug-in introduces some nasty clicks in the audio (on windows 7 at least).
- Default settings
- Audacity 2.0.6a
- with music or chirp tone
- 44100 Hz
- buffer 8192
- compensation on

I will have to investigate that

BTW: Does this only happen with Audacity 2.0.6a, or can you reproduce it in, e.g., Acoustica or GoldWave?

I think you should give some more descriptive names for the sliders i.e. write them out--meant for text only Gui and screen reader.

I wish I could. But the maximum length of the string that can be returned by getParameterName() without risking a buffer overflow is kVstMaxParamStrLen, which is defined as 8

(That's a limitation of the VST interface. Audacity can do nothing about this. Even if Audacity did allow for longer strings, other VST hosts may not. So a VST plug-in has to stay within kVstMaxParamStrLen to avoid crashes)

Where has the boundary setting gone to?

Another limitation of VST

The VST interface is designed to process an ongoing sequence of samples. I think the designers of VST were focused on "live" applications. Therefore, the plug-in has no way to tell when we have reached the end of the file. If we are processing a file, the host stops feeding the plug-in with new input at some point, yes. But, after each processReplacing() call, the plug-in must expect that more input is going to arrive soon - which may happen or not.

Now you may think that at least the beginning of a file could be handled in a special way. But, if multiple files are processed in the same application, there is no guarantee that the particular application will unload and re-initialize the plug-in between the individual files. Instead, the application may decide to pump the different files trough the same plug-in instance. In this case, the plug-in has no way to recognize where one file ends and a new file begins.

So no dedicated handling of the "boundaries" is possible via VST. At least I have no idea how it could be possible...

You could also include the Readme.htm file in the archive, this would somewhat facilitate the test usage of your plug-in.

The README is generated and included in the "normal" release packages by my "release" script. Just not in the ZIP that I created manually for this thread

[Robert J. H.]

Thanks Gunnar
I only use Audacity because it is the most accessible audio editor.
I'm probably going to translate your plug-in into Nyquist code, it allows at least multi-pass. This would be very helpful to correct outlayers.
As far as I can see, the structure is mainly made up from convolving a peak or rms envelope by a Gaussian kernel.
Do your frames overlap? could this remedy the clicks?
I guess not since you've not encountered any problems in other hosts and the standalone version.

[Gunnar]

Your Vst plug-in introduces some nasty clicks in the audio (on windows 7 at least).
- Default settings
- Audacity 2.0.6a
- with music or chirp tone
- 44100 Hz
- buffer 8192
- compensation on

Okay, I was able to reproduce the problem. And not only in Audacity! It's another VST oddity. The processRepalce() function provides the next N input samples and, at the same time, consumes exactly N output samples - where N is dictated by the host application. So I must return N output samples, even when I don't have anything to return yet. At the beginning of the process, when we need to fill the internal buffer first, the only possible way to workaround this limitation of VST is returning some silence. This unavoidably introduces a certain delay to the audio. Fortunately, starting with version 2.0.6, Audacity will now compensate for the plug-in's delay nicely.

So, at the beginning of the process, the delay cannot be avoided. But the actual problem was that my "core" library sometimes returned slightly less than N samples, even somewhere in the middle of the process! This was never a problem with the command-line program, since the command-line program doesn't care. It just writes as many samples to the output file as it got from the library. That's why the issue remained unnoticed until now. But the VST plug-in still needs to return exactly N samples to the host application in every single call. This caused a few silent samples to be insert every now and then. And those "gaps" cause the "nasty clicks" sounds you were hearing.

I have now implemented a workaround and the problem should be gone. Link in first post has been updated!

I'm probably going to translate your plug-in into Nyquist code, it allows at least multi-pass. This would be very helpful to correct outlayers.

Can Nyquist plug-in's make calls to "native" code?

As far as I can see, the structure is mainly made up from convolving a peak or rms envelope by a Gaussian kernel.

That's correct.

Do your frames overlap? could this remedy the clicks?

Nope, there's no overlap.

[Robert J. H.]

Okay, I was able to reproduce the problem. And not only in Audacity! It's another VST oddity. The processRepalce() function provides the next N input samples and, at the same time, consumes exactly N output samples - where N is dictated by the host application. So I must return N output samples, even when I don't have anything to return yet. At the beginning of the process, when we need to fill the internal buffer first, the only possible way to workaround this limitation of VST is returning some silence. This unavoidably introduces a certain delay to the audio. Fortunately, starting with version 2.0.6, Audacity will now compensate for the plug-in's delay nicely.

So, at the beginning of the process, the delay cannot be avoided. But the actual problem was that my "core" library sometimes returned slightly less than N samples, even somewhere in the middle of the process! This was never a problem with the command-line program, since the command-line program doesn't care. It just writes as many samples to the output file as it got from the library. That's why the issue remained unnoticed until now. But the VST plug-in still needs to return exactly N samples to the host application in every single call. This caused a few silent samples to be insert every now and then. And those "gaps" cause the "nasty clicks" sounds you were hearing.

I have now implemented a workaround and the problem should be gone. Link in first post has been updated!

Thanks a bunch.

I'm probably going to translate your plug-in into Nyquist code, it allows at least multi-pass. This would be very helpful to correct outlayers.

Can Nyquist plug-in's make calls to "native" code?

Unfortunately not (yet).
The code will perhaps be 20 times slower.
However, if it works now, there won't be any effort from my part be requested.
I just thought that your plug-in might be the right thing to adjust the variable levels of my guitar comping.

As far as I can see, the structure is mainly made up from convolving a peak or rms envelope by a Gaussian kernel.

That's correct.

It's of course more than that but the part that interests me most--mainly due to the adjustable smoothing with the Gauss.

Do your frames overlap? could this remedy the clicks?

Nope, there's no overlap.

Ok, the linear interpolation is probably enough, it depends a little bit on where the peaks occur, I guess.