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 1.3.1.2. 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. Ge!