On Mon, Sep 10, 2012 at 08:27:36AM -0400, plutek wrote:
nice little conversation with myself here! ;-)
so, thinking about this a little more, i'm wondering whether i'm missing some esoteric reason why this behaviour is useful -- i.e. letting a dysfunctional chuck run when it's started at a sample rate different from the jack server. might it be more useful in such a situation for chuck to quit, with an error message, "chuck must run at the same samplerate as jack -- please use the srate option.", or somesuch?!
It's a Linux problem at the start; I have no idea where the 48KHz default for so many Linux installs came from. The slightly higher frequency range isn't worth the conversion if you'd have to burn a CD. Anyway, I think this is what we need; http://jackaudio.org/files/docs/html/group__ServerControl.html#ga62022d4f2fb... A jack client can poll the server for its sample-rate. For Jack-ChucK that call should perhaps take the place of the default that the s-rate is set to when -sr[n] is not set at starting the VM. That way, if somebody does find a use for a mis-set -sr (s)he can and in other cases it should Just Work. Now we just need to hope that call is available in the same form for all editions of Jack ;-) If not I would lean towards requiring Jackd2, which is far more generous in what it accepts from clients, good for clients prone to experimentation. I did some development on connecting to Jack, but not too much and will defer to a actual expert if we have one. Yours, Kas.