[chuck-users] SndBuf causes hickup

[Leuthold Dominik]

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 at lists.cs.princeton.edu 
> [mailto:chuck-users-bounces at lists.cs.princeton.edu] Im 
> Auftrag von ssalazar at CS.Princeton.EDU
> Gesendet: Dienstag, 12. Juni 2007 22:36
> An: chuck-users at 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 <atte.jensen at gmail.com>:
> 
> > 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 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