From src/drumkitloasder.cc:

AudioFile *audiofile = load_queue.front();
load_queue.pop_front();
filename = audiofile->filename;
int preload_size = framesize * CHUNK_MULTIPLIER + framesize;
if(preload_size < 1024)
{
	preload_size = 1024;
}
 
// Note: Remove this line to enable diskstreaming
preload_size = ALL_SAMPLES;
 
audiofile->load(preload_size);

CHUNK_MULTIPLIER is a #define in src/audiocache.h:

#define CHUNK_MULTIPLIER 16

The loader code in src/audiocache.cc uses the macro CHUNKSIZE(framesize) for all it's chunk sizes. It is defined at the top of the same file:

#define CHUNKSIZE(x) (x * CHUNK_MULTIPLIER)

The framesize is an external parameter that is set indirectly through the setFrameSize method which again is called by DrumGizmo::setFrameSize in src/drumgizmo.cc

This call is controlled directly by the host, eg. via LV2 which can be set dynamically at runtime.

Ardour seem to use a “constant” upper limit defined byt the jack buffer size but can for a few buffer sometimes go lower than that limit. This can for example happen at the end of a loop where the loop point doesn't match the buffer size:

loop: sample 0 -> sample 2791
(sample 0) [buffer of 1024 samles] [buffer of 1024 samples] [buffer of 743 samples] -> goto sample 0

Situations like this need special attention in the code so we don't trigger a full kit reload on such a change.

Ideally we make the code completely independent of the framesize but this will probably cost extra CPU because we constantly need to process partial buffers.