Discussion about RealtimeEffectManager block sizes

[generic-pers0n]

@mmmaisel has raised the issue in their dynamic compressor that the block size RealtimeEffectManager provides is small. Additionally RealtimeEffectManager expects this same number of samples in return. For their new dynamic compressor, this is an issue due to latency. On the other hand, they recommend that latency compensation as a solution by allowing an effect to request a certain amount of samples in advance "at the beginning or when the user changes
settings."

Turns out that this might go nicely with moving realtime allocations out of RealtimeEffectManager, so I'd like to inquire further about this. Preallocating buffers in advance totally sounds like a good idea, especially given that I'm trying to implement this in other parts of AudioIO and RealtimeEffectManager.

[mmmaisel]

Just to clarify, the issue here is not processing speed or buffer sizes but computational latency,
usually caused by buffers or pipelines within the effect. A faster CPU or bigger buffers do not
change anything with respect to this issue.

To compensate this, the effect needs to tell the effect manager dynamically that is has a latency
of N samples that needs to be filled and drained. The amount of latency can change every time
the user modifies an effect setting.

E.g. an effect with 1 second lookahead fills its internal buffers with the samples of the
first second while still outputting zeros. At the end, the effect manager stopps generating
samples, as it thinks it is at the end, and cuts of the last second of the audio.

As solution, the effect manager has to supply N samples + the first buffer at the beginning
and discard the first N output samples. Then it can start with playback at the time "0" as usual
buffer by buffer. Please not that at this stage the actual playback and data-in time-points
are shifted by N samples. At the end, the effect manager has to continue to feed in N zeros,
and playing the remaining audio which exits the internal buffers.