[chuck-users] SndBuf causes hickup

Scott Wheeler 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.

-Scott


More information about the chuck-users mailing list