When testing my VST plug-in with Audacity (version 2.0.5), I noticed a strange behavior: Audacity will insert some silence at the beginning of the file, after the effect has been applied, so the whole audio gets shifted behind. That alone wouldn’t be a huge problem, but Audacity will also cut off the end of the audio file. At the same time other audio editors work flawlessly! So, as far as I can tell, this is some shortcoming on Audacity’s side. It seems Audacity totally ignores the delay reported by my plug-in.
I have created a few GIF animations in order to clearly illustrate the problem: Audacity VST issues
If you want to test yourself, I have put up a test version of the VST plug-in here: VST plug-in sample (x86/x64)
So is there any chance that this problem can be fixed?
And that’s because you in “moderation” until we can trust you.
Sorry but we had to implement this for new members as we were getting mountains of spam some of it unpleasant and some downright dangerous. We try to kep this a sane and family-friendly corner of cyberspace for our readers.
Actually, you do not have to bring any evidence–the problem is known.
Each Vst dialog of the version 2.0.6 has a special settings button where this offset can be corrected. It is presumably always the size of the fft that the plug-in uses.
This means that it is a power of two, e.g 1024, 2048, 4096 … samples correction will do the trick.
The new version is going to be released very soon.
Adding a way for the user to manually correct the plug-in’s internal delay is a firs step in the right direction. Though there are plug-in’s, like mine, that require a rather large buffer, that even depends in the concrete settings. So I hope this will be made flexible enough.
Anyway, I think that requiring the user to set up the delay manually is cannot be the final solution. VST plug-in’s do report their the delay to the host by calling setInitialDelay(), so that the host can compensate automatically. And most hosts (e.g. WaveLab, Audition, SoundForge and GoldWave - just to name a few) will do this just fine! I don’t know if all VST plug-in’s make use of setInitialDelay() in the proper way. So providing a manual method to the user probably is always a good idea. But I think for those plug-in’s that properly report their delay via setInitialDelay(), Audacity should take that value into account. If delay compensation will be implemented anyway, this shouldn’t be too hard, I suppose. And it would make Audacity behave much more similar to other audio editors with VST support…
BTW: Is there any test version of v2.0.6 available already?
Buffer Delay Compensation uses the delay reported by the plug-in. It is just a checkbox, enabled by default.
Whatever you set the buffer size to should affect the speed of processing, but the delay will be the same irrespective of buffer size if compensation is turned off.
When there is a 2.0.6 Release Candidate it will be posted in the Forum announcements. Meantime you can of course compile Audacity yourself or get the alpha build at the top of http://gaclrecords.org.uk/win-nightly/ .
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.
As far as I understand, “Buffer Size” simply controls the sampleFrames parameter of each processReplacing() replacing call, i.e. the number of input/output samples per call. If so, it shouldn’t matter for my plug-in much. That’s because it will simply add as many input samples to the internal “input” buffer as we got from the host. If enough input data has accumulated in the internal “input” buffer, we will process that data and add the results to our internal “output” buffer. Finally, we will copy back as much output samples from our internal “output” buffer to the host as we have ready. If we have fewer samples in the “output” buffer than the host has requested (via sampleFrames parameter) we return some silence. That’s because VST requires that we always return the same number of samples that we got as input. Of course, it can only happen at the beginning, that we need to return some silence.
If that does what I think, it would be exactly what I was hoping for
What I think this checkbox does, or better should do, is: If the VST plug-in has reported a delay of N samples to the host, via setInitialDelay(), then Audacity will discard the first N samples that are return by the plug-in, because those are just the “delay” samples (probably almost always nothing but silence). This could take several processReplacing() calls, since N can be bigger than “Buffer Size”. Furthermore, at the end of the process, after all input samples have been sent to the plug-in, Audacity sends another N “dummy” samples to the plug-in. This is required in order to “flush” the pending output samples from the plug-in’s internal buffer - it avoids truncation at the end of the file.
BTW: One interesting case is when N is not an exact multiple of “Buffer Size”.
I fully agree.
Thanks for the link. I will try this tomorrow. Need to get some sleep now
Does it crash inside the plug-in code or inside Audacity itself? In the latter case I would suspect a bug in Audacity. But will have to investigate…
BTW: I could reproduce the crash when repeatedly increasing the “Buffer Size”. I was able to track down the crash to a “double free” error inside the VST plug-in code.
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.
BTW: Does this only happen with Audacity 2.0.6a, or can you reproduce it in, e.g., Acoustica or GoldWave?
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)
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…
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
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.
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 exactlyN 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 exactlyN 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!
Can Nyquist plug-in’s make calls to “native” code?
[quote=“Robert J. H.”]
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.
[/quote]
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.
[quote=“Robert J. H.”]
As far as I can see, the structure is mainly made up from convolving a peak or rms envelope by a Gaussian kernel.
[/quote]
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.
[quote=“Robert J. H.”]
Do your frames overlap? could this remedy the clicks?
[/quote]
Nope, there’s no overlap.
Ok, the linear interpolation is probably enough, it depends a little bit on where the peaks occur, I guess.
