Resolved in a178437cd0ea591ee7e9f59841af015abb888779
The problem was that it was allocating memory on the audio thread, as well as well performing disk input on the audio thread. So a
worker thread was introduced, which regularly pumps new data into a FIFO buffer, ready to be moved into the audio buffer. For now the capacity of this buffer is set to 60000 frames. There are 2 additional std::vector buffers introduced: a L/R pair for storing input frames for the resampling process in, and a single channel for storing resampling output frames in. Both of these are also set to a capacity of 60000 frames.
These capacities should be ok for most audio interface buffer sizes people will use in practice, but some more fine-tuning could be applied to avoid problems in edge cases. It would also be interesting to determine the capacities based on the real spectrum of input parameters. But for that we would need to know which buffer sizes allowed on all 3 major operating systems for all audio driver APIs and so on.
Additionally there was a occasional glitch in the case where silence would be expected right before actually playing the sound. This was due to not silencing the output buffer passed into processAudio, and then leaking the audio input data that happened to be still in the buffer. We now silence the buffer both when it starts playing the sample, and when it ends playing, by checking whether the number of available frames is smaller than the number of frames requested to be generated/processed. This way we avoid redundant silence computation.
Resolved in a178437cd0ea591ee7e9f59841af015abb888779
The problem was that it was allocating memory on the audio thread, as well as well performing disk input on the audio thread. So a worker thread was introduced, which regularly pumps new data into a FIFO buffer, ready to be moved into the audio buffer. For now the capacity of this buffer is set to 60000 frames. There are 2 additional
std::vectorbuffers introduced: a L/R pair for storing input frames for the resampling process in, and a single channel for storing resampling output frames in. Both of these are also set to a capacity of 60000 frames.These capacities should be ok for most audio interface buffer sizes people will use in practice, but some more fine-tuning could be applied to avoid problems in edge cases. It would also be interesting to determine the capacities based on the real spectrum of input parameters. But for that we would need to know which buffer sizes allowed on all 3 major operating systems for all audio driver APIs and so on.
Additionally there was a occasional glitch in the case where silence would be expected right before actually playing the sound. This was due to not silencing the output buffer passed into
processAudio, and then leaking the audio input data that happened to be still in the buffer. We now silence the buffer both when it starts playing the sample, and when it ends playing, by checking whether the number of available frames is smaller than the number of frames requested to be generated/processed. This way we avoid redundant silence computation.