[chuck-users] 1.3.1 not happy with my jack (64-bit)
ge at ccrma.Stanford.EDU
Sat Sep 15 09:14:42 EDT 2012
> 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
22.214.171.124. 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