Re: [chuck-users] Urgent shot in the dark -- Audible clicks when spawning shreds when SndBuf reads from disk

Mike, "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 WvIn.h. 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! Andrew On Sun, Nov 8, 2009 at 10:10 AM, mike clemow 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 shreds.

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!!!

Mike

2009/11/8 Szilveszter Tóth :

...

Mike,

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ó:

...

Mike,

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.

Best, Mike

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users