[chuck] new user here with some questions

Ge Wang gewang at CS.Princeton.EDU
Thu Jul 28 00:17:49 EDT 2005


Greetings!

Welcome, Florian!  (I know (of) you from the LAD/LAU lists.)

At the moment ChucK is not behaving well under Linux-Jack, and we are 
committed to tracking this down and hopefully fixing it.  Dave 
Robillard and Gary Scavone (the author of RtAudio) and others have been 
helping.  Some restructuring of the underlying work-flow may be 
necessary to make ChucK play nice with Jack.  However, I am not 
familiar with Jack development, since we mainly develop on OS X 
CoreAudio / ALSA / Win32 DirectSound.  This may be a good time for me 
to get familiar with the workings of Jack finally.

I am going to fire up yet another Jack-support thread on chuck_dev, and 
we _shall_ get to the bottom of this.

Best,
Ge!

On Jul 27, 2005, at 3:14 PM, Florian Schmidt wrote:

>
> Hi,
>
> i'm a german nerd/musician and i'm plaing with chuck atm. I succesfully
> compiled the latest release for jack support. But it seems chuck has
> some RT issues.
>
> running the mand-o-matic example i get a cpu load of about 2-3% but
> xruns nonetheless. I run jackd at a buffer size of 256 frames atm 
> (which
> is plenty huge for my standards. i.e. i use 16 or 32 frames to apply
> realtime effects to my guitar via jack-rack - completely xrun free. 
> This
> is a nicely tuned realtime preemption system with a delta 66).
>
> I heard there's a 1.2 version in cvs. Does it have this kind of problem
> also?
>
> BTW: i get quite a few clicks/pops on moving windows/etc. even w/o
>
> RtApiJack: audio overrun/underrun reported!
>
> and xruns. But there's quite a few of these, too.
>
> Inspecting
>
> ~$ ps -C chuck -cmL
>   PID   LWP CLS PRI TTY          TIME CMD
> 23421     - -     - pts/6    00:00:07 chuck
>     - 23421 TS   24 -        00:00:04 -
>     - 23422 FF  109 -        00:00:02 -
>
> it seems to my uneducated eye, that chuck has two threads. One running
> SCHED_FIFO (probably the jack process() thread) and another SCHED_OTHER
> thread. Maybe the RT thread often waits for the SCHED_OTHER thread 
> which
> gets starved by other cpu activity (like moving windows, etc)
>
> If this is a RTFM! issue i will be happy to accept pointers.
>
> Flo
>
> -- 
> Palimm Palimm!
> http://affenbande.org/~tapas/
> _______________________________________________
> chuck mailing list
> chuck at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck



More information about the chuck mailing list