This is an old revision of the document!


Settings Analysis

From src/drumkitloader.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) [1024 samles] [1024 samples] [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.

Currently the AudioCache is dependent of the framesize, so if we just change the CHUNK_MULTIPLIER (which currently is the only control parameter existing in the code) we will not get the same result if we run with different jack buffer sizes. Needless to say that this is not what we want!

The chunk size is the same size used by the inner loop of the engine which expects the call to AudioCache::open and AudioCache::next to return a buffer of exactly that size.

A design where these methods still return buffer of that size but internally contains buffers of different (larger?) sizes might work just as well. In fact this is exactly what we currently do; each AudioCache chunk is precisely 16 times the size as the inner loop buffer. However, if we need to support arbitrary buffer size we need to be able to handle framesizes that are not a multiple of the chunk size, which will might introduce a calculation overhead.

Should we decide to simply use the multiplier in the UI (which would be the fastest way to achieve our goal) then we need to make absolutely sure that the, on a size change, the inner loop doesn't receive chunks from the “old size” but are expecting the new one. If the new size is smaller we might get memory corruption.

roadmap/settings_analysis.1484930066.txt.gz · Last modified: 2017/01/20 17:34 by deva
Trace: settings_analysis
GNU Free Documentation License 1.3
Valid CSS Driven by DokuWiki Recent changes RSS feed Valid XHTML 1.0