[chuck-users] Urgent shot in the dark -- Audible clicks when spawning shreds when SndBuf reads from disk
Andrew C. Smith
acsmith at willamette.edu
Sun Nov 8 10:21:44 EST 2009
"Frame" is just shorthand for (usually interleaved) samples for every
channel at a particular moment. So, a stereo frame is two samples,
quadrophonic frame is four samples, etc.
As another effort, WvIn says:
Small files are completely read into local memory
during instantiation. Large files are read
incrementally from disk. The file size threshold
and the increment size values are defined in
I did some sleuthing and the threshold is 5 MB (ugen_stk.h : 1106), so
if your files are larger than that than this might make it work. If
not, if nothing else works, and if you already have a working build,
you could try changing that line in ugen_stk.h and rebuilding to see
if it helps. Good luck!
On Sun, Nov 8, 2009 at 10:10 AM, mike clemow <gelfmuse at gmail.com> wrote:
> Hi Szilveszter, Kassen,
> Thanks for the quick response! It's definitely the reads between
> samples that's causing the issue, because I only kill the last shred
> twice during the piece. The dropouts occur only when spawning new
> I've already set the chunk-size to 1024... I assume that this is
> samples, although the documentation says "frames."
> I'll try preloading the files in a big array and see if I run out of RAM.
> Thanks so much!!!
> 2009/11/8 Szilveszter Tóth <silvestre.toth at gmail.com>:
>> if you record the audio from ChucK using a WvOut like this:
>> dac.chan(0) => Gain g => WvOut w => blackhole;
>> "tmp.wav" => w.wavFilename;
>> do you hear the click in the resulting tmp.wav? If not, then the problem is
>> with reading a file between samples. If yes, then the abrupt sample change
>> may play a role, too.
>> Szilveszter (Hillaby)
>> Szilveszter Tóth escribió:
>>> Just some thoughts.
>>> When you kill the "last shred" that was playing, the audio signal drops to
>>> 0 (or to the first sample of the next WAV file), which may cause clicks.
>>> Also, reading an entire file (or part of it) between two samples may not
>>> be feasible, which will not only cause a click, but the realtime timing will
>>> also be lost (ChucK will wait for the entire file to be read in.)
>>> I'd use an Envelope for the first problem and I'd try changing chunk size
>>> for the second. (Or maybe pre-read the next file to be played, if it can be
>>> determined beforehand.)
>>> I hope I could help a little
>>> Szilveszter (Hillaby)
>>> mike clemow escribió:
>>>> This is a shot-in-the-dark...
>>>> At the last minute, the person who was responsible for doing the sound
>>>> with a Kyma system, couldn't get it to trigger sounds with MIDI (for
>>>> some reason or another) and I'm stepping up and doing the whole show
>>>> with pre-recorded material in ChucK. (I know, I know -- I'm crazy.)
>>>> It's 9:25am here on the East Coast of the U.S. We're onstage at 2pm
>>>> and 8pm. I have a script that receives OSC messages from a Java
>>>> program. The messages contain the string name of a file to play.
>>>> It's a simple stereo file (I'm already working with a very kludgy way
>>>> of playing stereo files--loading it twice into two buffers). But
>>>> every time I spawn a new thread, the file loads from disk and there's
>>>> an audible click, or drop in audio.
>>>> Now, I know that one way around this is to pre-load all the files into
>>>> SndBuf objects and then trigger them to play using Events. The only
>>>> trouble is that there are 73 files for this piece and some of them are
>>>> pretty large. I'm afraid of eating all my RAM / bringing everything
>>>> to a grinding halt.
>>>> I'm posting my entire script at the end of the email. If anyone has
>>>> any thoughts, please send them along. Otherwise, we'll just deal with
>>>> the way things are.
>> chuck-users mailing list
>> chuck-users at lists.cs.princeton.edu
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
More information about the chuck-users