Re: [chuck-users] SndBuf causes hickup

hi all

SndBuf b; 1024 => b.chunks; "cowbell.wav" => b.read; aah, that's a great hint spencer.

on windows it also helps when you increase the latency. which isn't that great at all, but helped me avoiding the glitches. let's have a look how much i can decrease the latency now with this setting :-)) thanks /moudi

-----Ursprüngliche Nachricht----- Von: chuck-users-bounces@lists.cs.princeton.edu [mailto:chuck-users-bounces@lists.cs.princeton.edu] Im Auftrag von ssalazar@CS.Princeton.EDU Gesendet: Dienstag, 12. Juni 2007 22:36 An: chuck-users@lists.cs.princeton.edu Betreff: Re: [chuck-users] SndBuf causes hickup

Hey Atte, This is a known issue-- by default, SndBuf reads the entire file immediately when you specify the file path. Due to ChucK's strong-timing, this will stop audio processing until the file has finished loading from the disk into memory, which is typically long enough to underflow the audio buffer and cause audible hiccuping. Probably the best solution is to use the .chunks parameter-- you can use this to load audio frames on demand instead of all at once. E.g.

SndBuf b; 1024 => b.chunks; "cowbell.wav" => b.read;

will specify that the file is read 1024 frames at a time when those frames are needed, instead of all at once. See http://chuck.cs.princeton.edu/doc/program/ugen_full.html#sndbuf for more details. You might need to experiment with different values for .chunks, but that should be able to make the hiccuping go away.

spencer

Quoting Atte André Jensen :

...

Hi

I have (and have had for as long as I can remember) problems with SndBuf. I'm pretty sure the trouble is when loading a sample, then there will most often be a small but very noticeable hickup. It's quite bad with larger samples but also there with even small samples. Generally; the larger the sample, the greater the hickup.

The problem seems to be gone or almost gone when the sample has already been loaded once, but this might be due to caching in the underlying os.

I've tested with both alsa and jack, and all kinds of combinations of buffersizes and what have you, but although the problem seems the vary a bit (in an unpredictable pattern) it's always there. I also tested both syntaxes ("sample" => s.read and s.read("sample")), however only with wav files. I also tried both in miniAudicle and commandline chuck.

Needless to say this makes SndBuf useless on my system :-(

Is this a result of me doing something wrong or a bug in chuck? In any case is there anything I can do to remedy this right now? If it's a bug, I'd be most happy to help in any way I can with getting it fixed as soon as the developers time permits.

BTW: This is under linux (debian/stable) on a IBM T41, 1.6Ghz, 1G ram and 7200 RPM HD. The system is running with a realtime patched kernel and is capable of playing back 20+ tracks in ardour with effects + various soft synths running along in realtime without a single xrun or glitch.

Here's a simple example of something that shows the problem: http://atte.dk/download/sndbuf_test.tgz. First run shaker.ck, then after a while add substitution.ck (a beat => big hickup) or sd.ck (a snare drum => small hickup).

-- peace, love & harmony Atte

http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://atte.dk/compositions _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

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