Re: [chuck-users] 1.3.1 not happy with my jack (64-bit)
BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }ack.... oops!! so excited about firing up 64-bit chuck, i forgot about the 48k default sampling rate! chuck --srate44100 ....fixes everything. sorry for the noise... cheers! .pltk. On Sun 09/09/12 8:42 PM , plutek plutek@infinity.net sent: greetings! i just compiled 1.3.1 on a 64-bit linux system. compilation for jack went fine, and chuck runs without error messages. however.... no jack client is created. (so, of course, i hear nothing) shreds don't actually get started. (i.e. chuck ^ shows NOTHING) when i stop chuck, it says: RtApiJack::closeStream(): no open stream to close! if i run with --silent, incoming shreds DO show up. my jack is working fine with other applications. any clues? what shall i send to help figure this out? thanks much... cheers! .pltk. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu [1] https://lists.cs.princeton.edu/mailman/listinfo/chuck-users Links: ------ [1] mailto:chuck-users@lists.cs.princeton.edu
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?!
cheers!
.pltk.
From: Peter Lutek
ack.... oops!! so excited about firing up 64-bit chuck, i forgot about the 48k default sampling rate! chuck --srate44100 ....fixes everything. sorry for the noise... cheers! .pltk. On Sun 09/09/12 8:42 PM , plutek plutek@infinity.net sent: greetings! i just compiled 1.3.1 on a 64-bit linux system. compilation for jack went fine, and chuck runs without error messages. however.... no jack client is created. (so, of course, i hear nothing) shreds don't actually get started. (i.e. chuck ^ shows NOTHING) when i stop chuck, it says: RtApiJack::closeStream(): no open stream to close! if i run with --silent, incoming shreds DO show up. my jack is working fine with other applications. any clues? what shall i send to help figure this out? thanks much... cheers! .pltk. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu [1] https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Links: ------ [1] mailto:chuck-users@lists.cs.princeton.edu
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.
On 09/10/2012 06:13 AM, Kassen wrote:
Now we just need to hope that call is available in the same form for all editions of Jack ;-)
All jacks are api compatible AFAIK... if not it is a bug... I agree that chuck should complain at least, and not fail silently. It might depend on how rt-audio handles this (maybe there is an error return being ignored?) -- Fernando
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.
On Mon, Sep 10, 2012 at 01:30:37PM -0700, Fernando Lopez-Lezcano wrote:
On 09/10/2012 06:13 AM, Kassen wrote:
Now we just need to hope that call is available in the same form for all editions of Jack ;-)
All jacks are api compatible AFAIK... if not it is a bug...
If I remember right there are at least differences in the name of the system/soundcard's outputs, which will affected making scripted or automatic connections to those. Not the end of the world, but it is a difference.
I agree that chuck should complain at least, and not fail silently. It might depend on how rt-audio handles this (maybe there is an error return being ignored?)
Yes. No silent failing and I also think that there is no need to bother the user with typing in numbers that ChucK could find on its own at least as well. Keeping the "-sr" parameter a option could still be nice, for example if we'd like to set the samplerate because we want to be sure that the system is set up like we want our synth to be. Yours, Kas.
Hi all! On Mon, 10 Sep 2012, Kassen wrote:
On Mon, Sep 10, 2012 at 01:30:37PM -0700, Fernando Lopez-Lezcano wrote:
I agree that chuck should complain at least, and not fail silently. It might depend on how rt-audio handles this (maybe there is an error return being ignored?)
Yes. No silent failing and I also think that there is no need to bother the user with typing in numbers that ChucK could find on its own at least as well.
Definitely agree! I previously thought there was some kind of error reporting, but something seems missing or broken. Will look into for next release!
Keeping the "-sr" parameter a option could still be nice, for example if we'd like to set the samplerate because we want to be sure that the system is set up like we want our synth to be.
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? Ge!
From: Ge Wang
Hi all!
On Mon, 10 Sep 2012, Kassen wrote:
On Mon, Sep 10, 2012 at 01:30:37PM -0700, Fernando Lopez-Lezcano wrote:
I agree that chuck should complain at least, and not fail silently. It might depend on how rt-audio handles this (maybe there is an error return being ignored?)
Yes. No silent failing and I also think that there is no need to bother the user with typing in numbers that ChucK could find on its own at least as well.
Definitely agree! I previously thought there was some kind of error reporting, but something seems missing or broken. Will look into for next release!
Keeping the "-sr" parameter a option could still be nice, for example if we'd like to set the samplerate because we want to be sure that the system is set up like we want our synth to be.
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?
Ge!
as the humble OP for this thread, i'd say that sounds fantastic! :-) cheers! .pltk.
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. Kas.
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!
participants (5)
-
Fernando Lopez-Lezcano -
Ge Wang -
Kassen -
Peter Lutek -
plutek