Hi there, 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. Here's how I repro the issue (running on a late-model 2.13GHz MacBook Air): SndBuf buf[512]; // gets more responsive as I reduce to <384 or so fun void connect(SndBuf b) { b => dac; } for (0 => int i; i < buf.cap(); i++) { spork ~ connect(buf[i]); } while (1::second => now) <<< now >>>; 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. Thanks a bunch! -josh
Josh; 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.
It depends. If you actually want to play back over a thousand samples as the same time then there might be a problem... However it sounds a bit like you just want to have them all ready at any moment, and only play a selection of those samples at a time. The most easy way to save CPU here is to instantiate the buffers and load the samples but not connect them to the dac. Without a dac connection they should not take cpu. You would then connect the buffer(s) you want to play when you need them and after you are done with a sample "unchuck" the corresponding buffer from the dac using "my_buf =< dac;". This will save you a lot of CPU and the only cost will be in memory (aside of course from loading the samples initially, with that amount of samples that might still be a lengthy process). Hope that helps, Kas.
Hey Kassen,
2011/4/16 Kassen
It depends. If you actually want to play back over a thousand samples as the same time then there might be a problem... However it sounds a bit like you just want to have them all ready at any moment, and only play a selection of those samples at a time.
Yes, that's correct.
The most easy way to save CPU here is to instantiate the buffers and load the samples but not connect them to the dac. Without a dac connection they should not take cpu. You would then connect the buffer(s) you want to play when you need them and after you are done with a sample "unchuck" the corresponding buffer from the dac using "my_buf =< dac;".
Thanks, this sounds reasonable.
This will save you a lot of CPU and the only cost will be in memory (aside of course from loading the samples initially, with that amount of samples that might still be a lengthy process).
That makes sense. I'm ok with an initial loading lag and the samples will always fit in memory so this'll be ok.
Hope that helps,
Definitely does and I certainly appreciate the quick and thorough response! Cheers, -josh
Hey there, I've got a couple more puzzlers roughly on the same topic: Can I get SndBuf to tell me when buf.chunks have been successfully read into memory so that I don't spend too much time waiting on buf => blackhole? Can SndBuf report when it has a problem keeping up with file loading during playback? I can generally hear problems just fine, it's just that it I'd like to write automated tests around this kind of output so I don't have to sit and listen every time I run a test that stresses the UGen. This would also make it possible to know when there are problems creeping up that are harder to hear. Thanks! -josh
participants (2)
-
Josh Adams -
Kassen