In developing some plugins I experienced issues with version 10 Steinberg products (WaveLab LE 10 for example) that don’t occur in prior versions. On debugging I found the cause of the issue and have worked around it but the behaviour of WaveLab 10 seems inconsistent to how I would expect it to behave given the documented VST3 standard.
The issue is as follows. When WaveLab calls setupProcessing() on my plugin the maxSamplesPerBlock attribute of the ProcessSetup argument is set to 4096 samples (in my driver setup case of course, will depend on WaveLab cofig.) but then when process() is called the the numSamples attribute of ProcessData passed in the call is always 1024 samples! My bugs were caused by the fact that my processing assumed it would be processing a maximum of 4096 samples but it only ever got 1024 samples. I’ve never seen this behaviour in any other hosting product.
Although I was able to work around this it is problematic behaviour for algorithms that require fixed block processing such as FFT based fast convolution because I can only setup the processing based on what is told to me in the setupProcessing() call so will be creating a processing scheme that is not CPU efficient because I’ll only ever be processing 1/4 of what I was told I was going to be processing and discarding the rest.
Can anyone explain this behaviour and justify it, or am I correct in thinking that this is a release 10 bug?
Hi
no this behaviour is OK, maxSamplesPerBlock indicates only the potential max number of Samples per audio block which could be used in a process call.
For block processing requiring a fixed size, for example FFT, the plug-in has to implement a kind of ringbuffer filled with the audio block passed when processing, and process its wanted block size when there is enough audio in ringbuffer, in this case the plug-in has to report an audio latency equals to its internal processing blocksize.
Like I say, I can work around it but I cannot make it optimal because to do so requires knowledge of the block size that is going to be used during processing which WAVELAB does not do. For instance, If setupProcessing() says the max buffer is 4096 then I use that to implement convolution with 8192pt FFTs but using processing of that size and discarding 3/4 of the samples because the processing call only ever passes 1024 samples. Using a smaller FFT size in a ring buffer is less efficient than a larger one tailored to the actual usage so it is important to have a realistic idea of how many samples will be used. The fact that WAVELAB reports 4 times the size that it ever uses just isn’t logical. Why report 4 times the size given it never uses it. I haven’t tested this extensively but I certainly hope it doesn’t get worse if a shorter output device latency is chosen (ie. set the latency to 256 samples and it still calls setupProcessing() with 4096).
I did not write the VST3 spec, nor am I an expert, but it seems pretty clear to me from the documentation that:
a) the number of samples you receive on each frame will always be less than or equal to maxSamplesPerBlock provided in setupProcessing
b) but more importantly, it can vary from frame to frame (with maxSamplesPerBlock being the upper bound). The fact that the number of samples is provided with each frame call, is an indication that you cannot rely on this number to even be consistent from frame to frame.
The way you describe Wavelab to be behaving is following these rules and I think it is best to design your plugin according to it because another DAW may also work in a similar fashion especially since this is how the spec is written.
Whatever algorithm you implement simply need to define its own “window” and accumulate samples until it is full (which may even fall in a middle of a frame…)
BTW, an idea for VST3PluginTestHost would be to allow for variable frame sizes as an option to test that a plugin is handling non consistent frame sizes properly…
Block Size: Processing is done in blocks. The maximum number of samples to be processed in one block is set in Steinberg::Vst::IAudioProcessor::setupProcessing. The actual number of samples in a processing block is transmitted in the process call and can be different from call to call, but it must be a value between 1 and maxSamplesPerBlock.