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/PluginProcessor.cpp#L297
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
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
