<div>Hi there,</div><div><br></div><div>I found a thread or two in the past that talked a little about this.  I'm hoping that in the time since those discussions there've been some internal improvements to ChucK that might help me have a bunch of samples ready to fire concurrently without eating my box alive.</div>

<div><br></div><div>Here's how I repro the issue (running on a late-model 2.13GHz MacBook Air):</div><div><br></div><div>  SndBuf buf[512]; // gets more responsive as I reduce to <384 or so</div><div>  fun void connect(SndBuf b) { b => dac; }</div>

<div>  for (0 => int i; i < buf.cap(); i++) { spork ~ connect(buf[i]); }</div><div>  while (1::second => now) <<< now >>>;</div><div><br></div><div>If there's nothing I can do about SndBuf's wasteful behavior is there a better/more ChucKian-approved way to prepare a bunch of independent audio buffers (hopefully >1024) for arbitrarily-timed concurrent playback?  Really hoping that the answer isn't that I need more cpu cycles on that core and/or that I'll need to distribute ChucK and set up some kind of sync mechanism :-/.  I have very similar performance results with WvIn btw.</div>

<div><br></div><div>Thanks a bunch!</div><div>-josh</div>