[chuck-users] SndBuf causes hickup
wheeler at kde.org
Thu Jun 14 20:13:44 EDT 2007
Atte André Jensen wrote:
> Drew Jaworski wrote:
>> Here's what I do when using SndBuf:.
>> This is just a quick and dirty copypasta of a random old project, so
>> replace the files with any random percussive sounds you have, and
>> something interesting should arise. :P
> I'm still not able to get satisfying results. With something similar to
> your example I use about 25% for miniAudicle without doing anything
> (except having the samples loaded). Might be because I have the SndBuf's
> connected to dac. This is getting too complicated for me.
> However a friendly geek from my local LAU suggested [...]
Just another friendly, geeeky, explanation of what you're seeing -- when
you cat everything to /dev/null, that effectively puts all of those
samples into memory. The operating system has to read all of the files,
even to write their contents to a fake device, and they stay in a
special place in memory called disk cache until that memory is needed
for something else.
However, that's not connected to CPU performance; it's much more
connected to hard drive speed and more specifically how the OS
prioritizes different operations and how much of the file system
information it keeps in memory.
The first time that you open those files, the hard disk has to spin up,
figure out where those files are, open them and start reading data.
Many file systems on Linux typically, for things not in the previously
mentioned disk cache, are pretty slow doing that. If you think about
what's physically happening (a motor starting, a robotic arm moving to
the right place). Pretty good average latency for "seek time" on a hard
drive, not counting OS overhead, is about 10 ms -- which is notably
longer than 4 or 5 that you're trying to achieve -- and that's per file.
Solving that either means pre-fetching those files into memory (either
explicitly by the user or automatically or using a trick like the "cat"
above). Pre-allocating buffers before the sound starts, or in a
background shred should do the trick. Unfortunately predicting which
samples are about to be played is a bit trickier for ChucK than say in a
sequencer and even the sequencer that I use (Live) has a button for
explicitly placing samples in RAM.
More information about the chuck-users