handling a lot of audio samples

Ward

I'm building an instrument which uses a lot of different samples. One sample might be used by different tracks/parts of the instrument.

I read some manuals of different embedded sampling instruments and it seems most use the following strategy:
- samples are loaded from the disk into a sample pool (which usually has a fixed size)
- the sample playback object chooses a sample from the sample pool and reads samples from it

I thought of implementing it like this:

class AudioResource
{
	std::string filename;

	// vector of channels containing a vector of samples
	std::vector<std::vector<float>> buffer;
};

// shared pool
std::vector<AudioResource> samplePool;

// load new sample in slot x
// this line will be called inside an aux task
samplePool[x].buffer = AudioFileUtilities::load(gFilename);

// access audio samples from the sample in slot x
buffer[x].buffer[channel][frame];

Now I wonder about (re)allocation. The samplePool might grow up to somewhere in the 200-400 MB range. The samples will be accessed in a random(ish) way (i.e. granular synthesis, loop slicing). Therefore loading only parts of an audio sample and loading the next part if it's almost needed does not suffice

If I add or remove a new sample to the shared pool, does the complete samplePool vector reallocate to stay contiguous in memory? If yes, it seems to me that loading new samples takes more time each iteration right?

If I replace a sample by loading a new sample into samplePool[x].buffer (and thus resizing buffer), does the entirety of samplePool reallocate if buffer grows (or shrinks) in size?

Should I even use std::vector for the shared pool? Is there another container better suited for this?

I watched this video which mentions using a custom allocator which uses preallocated memory. Could this be relevant here? This seems to solve the "allocation takes too much time inside an audio callback" issue, but that's not really an issue for me if I use auxiliary tasks for loading samples..

giuliomoro

	std::vector<std::vector, float> buffer;

this is not valid syntax

Ward If I add or remove a new sample to the shared pool, does the complete samplePool vector reallocate to stay contiguous in memory?

It depend on how you remove elements from it. It may reallocate, but it will only reallocate the AudioResource elements (which are relatively small) and not the data() of their buffer elements, which is where the bulk of your memory will be. Besides the cost of reallocation, one side issue you get is that while the memory is being reallocated the samplePool is in an invalid state and should not be accessed from the other threads (e.g.: audio thread). If the audio thread already holds a reference to the data() and a copy of the size() of the relevant buffer element, you should be fine to keep accessing it. If not, there are typically two strategies for adding/removing elements at arbitrary places without causing reallocation of the elements of samplePool. One is to keep it a vector, set it to a fixed size and mark individual elements arrays as disabled. When you need a new element you search for the first disabled one and you construct your new element there. The other is to use a different container that is designed for constant time insertion and removal at arbitrary places, such as std::list.

From here:

Adding, removing and moving the elements within the list or across several lists does not invalidate the iterators or references. An iterator is invalidated only when the corresponding element is deleted.

Ward If I replace a sample by loading a new sample into samplePool[x].buffer (and thus resizing buffer), does the entirety of samplePool reallocate if buffer grows (or shrinks) in size?

no. Keep in mind that sizeof(std::vector<WHATEVER>) is fixed (typically 12 bytes on a 32 bit system: 4 bytes for a pointer to the data, 4 bytes for size_t which denotes the amount of memory allocated at data() (can be larger than the actual number of elements and is normally managed automatically unless you call reserve() or shrink_to_fit()), 4 bytes for a size_t which denotes the number of valid element (following calls to resize() or push_... or emplace... ). So, changing the size of data in buffer won't change the size of the AudioResource object containing it and therefore won't cause anything to change in samplePool.

Ward which mentions using a custom allocator which uses preallocated memory.

I don't think this is necessary relevant to your use case. However, depending on the amount of memory you are allocating each time (say that you load thousands of buffers that are 2.5kb long), you may end up with fragmented memory using the standard allocator and may have to resort to a pre-allocated pool and a smart allocator of your own. But as long as you are allocating memory in large chunks (e.g.: MB) you shouldn't have to worry about this.