Audacity Forum

Hello.

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?

Kind Regards.

The ZIP archive is Password Protected.

Koz

kozikowski wrote:The ZIP archive is Password Protected.

Koz

Sorry, I was about to add the password to my post. But my post didn't actually appear on the forum until this morning. Will add the PW right now!

-

Gunnar wrote:Hmpf, for some reason this forum neither allows me to edit my own post nor to send you a person message

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.

WC

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.

Robert J. H. wrote: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.

Thanks for the info, Robert!

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?

Regards.

Here is the dialogue:


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.


Gale

Gale Andrews wrote:Here is the dialogue:

Interesting!

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.

Gale Andrews wrote:Buffer Delay Compensation uses the delay reported by the plug-in. It is just a checkbox, enabled by default.

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".

Gale Andrews wrote: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.

I fully agree.

Gale Andrews wrote: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/ .

Thanks for the link. I will try this tomorrow. Need to get some sleep now

Gale Andrews wrote: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.

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...

Regards.

[quote="Gale Andrews"]Buffer Delay Compensation uses the delay reported by the plug-in. It is just a checkbox, enabled by default.

Okay, today I have tested the latest Audacity 2.0.6 nightly build!

First of all I can confirm that "Buffer Delay Compensation" works as expected. No more shift, no more truncation. Great improvement, Audacity team!
Audacity VST issues (UPDATED)

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.

I will upload a fixed version very soon...

Regards.