[chuck-users] 1.3.1 not happy with my jack (64-bit)

Ge Wang ge at ccrma.Stanford.EDU
Sat Sep 15 09:14:42 EDT 2012

Hi all!

> On Mon, Sep 10, 2012 at 10:57:54PM -0700, Ge Wang wrote:
>> Perhaps the behavior on linux/jack should be: try to figure out and use 
>> the in progress JACK sample rate by default, unless the --srate:<N> 
>> flag is present, in which case it will try to use the specified <N>. 
>> If any unrecoverable, showstopping failure is encountered along the way 
>> (e.g., can't start audio, hah), then fail with clear error message. 
>> Sound good?
> Yes, totally.
> Even for Jack-ChucK being unable to poll the Jack server for the rate 
> should likely result in at least a warning. We have seen quite a few 
> reports about that old package that was meant for Jack, yet distributed 
> towards people apparently unaware of the need to start the Jack server.
> None of this is very hard; the Jack interface is quite well documented, 
> hardest might be writing error messages that cover what might be wrong 
> in a friendly way.

Alrighty!  this behavior has been implemented (is in svn) and will be in  Now there is a clear error message if it can't attach to JACK 
due to sample rate problem.  If --srate is specified, it will try to use 
that (and fail if it can't).  By default (--srate no specified), if there 
is a rate mismatch, it will automatically use the device info to use the 
next highest or the closest (in that order).  This behavior is intended 
for all supported platforms, including JACK, though there may be some 
differences in nuance.


More information about the chuck-users mailing list