Apparently some applications on some OSes allow the user to set any buffer size in their audio settings. Sometimes the buffer size will be a slider to set any value small to large.
One user of our VST3 plugin running libpd inside complained about sporadic crackles and discontinuities in the audio.
The user was running the plugin in Reaper on the Mac with a buffer size of 1200.
It never even occurred to me to even test other buffer sizes than 64, 128, 512, 1024.
However apparently Reaper allows these settings and they will lead to discontinuities since Pd and therefore libpd aren't prepared for such arbitrary buffer sizes. We could add more ring buffers in our plugin code, but this would introduce latency for everyone else.
Just wanted to share this here, since it is something to consider for libpd implementations.
m.
It never even occurred to me to even test other buffer sizes than 64, 128, 512, 1024.
Never assume that hardware buffer sizes are a power-of-2! There are even some built-in sound cards that *only* run on a single fixed weird buffer size.
Conversely, never assume that all audio processing algorithms run at power-of-2 block sizes. For example, the Opus encoder/decoder requires block sizes like 120, 240, 480, 960, etc. (multiples of 2.5 ms @ 48 kHz).
Finally, be aware that VST plugins don't use a fixed block size! The block size passed to the setup function (VST3: "maxSamplesPerBlock" in "Vst::ProcessSetup") is only the *maximum* number of samples you will ever attempt to process. The actual number of samples passed to the process function (VST3: "numSamples" in "Vst::ProcessData") can vary between processing calls! This is necessary so that DAWs can process "incomplete" blocks, e.g. for playback start, for accurate looping or before tempo changes (so that the tempo change happens exactly at the start of a block).
If a processor depends on a fixed processing block size - as is the case with Pd - you generally have to buffer the inputs/outputs. This obviously adds latency, but most DAWs have latency compensation.
Note that you also have to buffer MIDI messages (and use appropriate time stamps)!
For example, this is what Camomile does: https://github.com/pierreguillot/Camomile/blob/dev/v1.0.8/Source/PluginProce...
One general problem to be aware of: Once a processing block is smaller than or not a multiple of DEFDACBLKSIZE, all following blocks will effectively be offset by that amount of samples. For MIDI messages this is not a real issue because they are timestamped. However, any kind of transport information, like the project play head or tempo changes, is only provided once per block. If the plugin relies on this information, the output might not be perfectly aligned with the rest of the project.
Of course, it would be nice if this was already handled in libpd itself (as an option). Buffering the audio input/output would be the easy part. libpd would also have to automatically delay incoming MIDI messages and buffer + delay outgoing MIDI messages. I think it's doable, but it's not trivial.
Christof
-
Christof Ressi -
Max