[chuck-users] Windows XP - setting chuck.exe to "realtime" priority

[David Powers]

Hi Ge,

I was running the stk/clarinet.ck example. No soundfiles involved at all. It
was usually only in creating and destroying shreds that there was a problem.
Actually, now that I think about it, glitching also occurred when I would
change focus to another program and carry out some action, i.e. scrolling
through the chuck manual in Adobe Reader. This is on an Intel with Pentium
M, running Windows XP Pro with SP2.

The PIII was running the same version of chuck, 1.2.0.5; the only difference
I can think of, offhand, is that it was running an older version of Windows
XP Pro, with either SP1, or no service packs at all. So possibly it's an
issue with something in SP1 or SP2.

Unfortunately, I am planning to use chuck with a MIDI controller and
joystick, so latency is an issue. I have a performance coming up on April
30th, with an electroacoustic ensemble, so I will be interacting with
improvising instrumentalists in real time. I'd love to use chuck, if the
performance is good enough.

I do have a cheap M-Audio MobilePre USB soundbox, which I haven't yet tested
with chuck. Possibly that will help with the glitching problem. However, if
I need to boost chuck's priority, and it works, then I'm perfectly willing
to do that. Is there any reason I SHOULDN'T do so?

Btw Ge, I was at your presentation last Tuesday in Chicago (DorkBot
meeting), which got me excited about chuck gave me the idea to try chuck for
the upcoming performance. I'm really excited to see this software develop
further!

~David

On 4/20/06, Ge Wang <gewang at cs.princeton.edu> wrote:
>
> Hi David!
>
> > However, to get it to run well on my new Dell laptop running WinCrap XP,
> > I had to go CTL-ALT-DEL, open up processes, and set the priority of
> > chuck.exeto "realtime". Otherwise, when I create and delete shreds, I
> > was getting unwanted glitching. Is there some way to automate this
> > process, so that chuck always has realtime priority? A command line flag
> > would be really helpful I guess.
>
> On windows, there isn't a way to automatically boost the priority (and
> usually shouldn't have to).  This glitching on windows seems to be a new
> feature of 1.2.0.5.  One way to alleviate the problem is to specify a
> larger audio buffersize (which will increase your latency, but doesn't
> matter too much if you aren't using interactive input, like joystick, kb,
> etc.):
>
>      > chuck --bufsize2048
>
> for example, sets the buffer size to 2048.  Try different powers of two.
>
> > Also, is it normal for me to need to do this?
>
> Hmm, one shouldn't have to do this...  We hope to track the cause down for
> the next release.  It may have something to do with loading sound files,
> the implementation for that did change a little.  Do these shreds that
> glitch load sound files?
>
> > Strangely, despite maxing out the CPU, on an old PIII desktop with only
> > 256 MB RAM (as opposed to 1 gig on the laptop) I had no problems like
> > this and creating and deleting shreds occurred very smoothly. That was
> > with a clean install of WinCrap, however.
>
> That is strange, were both computers running the same version of chuck?
> If not, you might try running the PIII chuck on your new computer.
>
> We hope to fix this soon.
>
> Best,
> Ge!
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20060420/15eb4c25/attachment.htm