Table of Contents

Disk Streaming

Goals: Load only a minimal amount of sample data from the disk on load, and then read in chunks just-in-time.
The following properties should be fulfilled:

  • The memory usage should remain (relatively) constant during operation regardless of the number of samples played simultaneously.
  • Look-ahead cannot be used. Everything must be real-time.
  • The performance must not degrade to a point where it is compromising the audio quality.
  • For live performance purposes, it should be possible to signify which channels should be dropped in case of overload (eg. the AMB channels may not be as important as the snare-top on a snare hit).
  • The user should be able to tweak the preload memory usage as well as chunk sizes and other parameters.
  • The user should be able to completely bypass the feature and read in all samples into memory.
  • Presets with parameters matching different architectures/system types should be supplied (SSD, spinning disk, fast cpu/slow disk, fast disk/slow cpu, etc…)


  • Each sample has an initial chunk loaded on drumkit load time. This data is stored in the AudioFile object. The initial chunksize can be set to “full” to adapt the current behavior of loading all samples fully into memory (ie. disable disk streaming).
  • Once the sample gets triggered by an input event a EventSample object is allocated containing a sample position t as well as a pointer to the AudioFile object containing the preloaded data. The fron-buffer is initially set to point to the preloaded data.
  • On each run iteration, the sample counter t is incremented.
  • Once the value of t reaches the “trigger point 1”, the loader is signalet to start loading chunk1 into the back-buffer of the EventSample object.
  • Once the value of t reaches the end of the front-buffer, the back and front buffers are switched and the “internal” buffer pointer is set to 0.
  • When the value of t reaches “trigger point 2” the loader is signaled to start loading chunk2 into tyhe back-buffer.
  • … and so on and so forth - until the end of the sample has been reached …

The samples are stored in multi-channel wav files, so we want to read in multiple channels at once in the loader thread since all channels are played (and therefore loaded) in parallel. Therefore the EventSample should be referencing the Sample object and not the AudioFile object alone…


Receives events/queries for chunk loading.

Request : (filename/ref, channelnumber, position [size from manager??])

If filename/ref and position is the same on consecutive requests, but the channel numbers are different, the requests are reads from the same multi-channel file and is to be collapsed into a single read with writes to multiple buffers.

Once a file is opened, it should stay opened as long as the sample is active.

dev/disk_streaming.txt · Last modified: 2015/04/09 17:35 by deva
Trace: disk_streaming
GNU Free Documentation License 1.3
Valid CSS Driven by DokuWiki Recent changes RSS feed Valid XHTML 1.0