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

mike clemow gelfmuse at gmail.com
Sun Nov 8 11:45:39 EST 2009


Oh...  wait, I'm using SndBuf, not WvIn.  Should I not do that?

I'm going to try to re-write this to pre-load and see what happens...

thanks for all your help!


On Sun, Nov 8, 2009 at 10:21 AM, Andrew C. Smith <acsmith at willamette.edu> wrote:
> 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 <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
>> 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 <silvestre.toth at gmail.com>:
>>> 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 at 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 at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users


More information about the chuck-users mailing list