13 Jun
2011
13 Jun
'11
3:02 a.m.
On Sun, Jun 12, 2011 at 8:30 PM, Aaron Krister Johnson
<aaron(a)akjmusic.com> wrote:
well, JACK Session springs to mind. this should be taken up on the
jack mailing list rather than here.
PianoTeq doesn't configure things when jack is
running. It just detects and
runs with what jack's setting are. However, the *user* configures things
when Alsa is running. Things like sr, buffer sizes, and periods. I was
comparing apples to apples when I announced my results: for instance, if I
set PT to run Alsa @ 256 samples and 2 buffers per period, I also ran jackd
with those setting before starting PT.
I'd love your insight into what could have been going on; things seem quite
a bit better with jack2 (jackdmp-1.9.7) on my system---and, like I said, all
would it be so hard to just run that very simple command i asked
about? you have absolutely no guarantee that the parameters presented
by Pianoteq translate directly into ALSA driver parameters, though
they probably do. i gave you a very, very simple way to make sure of
this but we still seem to be arguing about whether to run it or not.
JACK requires context switching out of the program woken by the device
driver (jackd) to the client (pianoteq) and back again. This tends to
expose just any weakness in your system setup that relates to process
scheduling. When an app (pianoteq) deals directly with ALSA, this
context switching is avoided. Its very cheap computationally
(relatively speaking), but it is subject to system-induced snafus.
yeah, its in
the backlog at present. its functionality overlaps quite
a lot of other stuff.
Hmmm....like what, Qjackctl? That's a GUI, this is CL. And the CL tools that
currently come with jack do the trick, but with needless typing and lack of
ease---that's what my-front end solves. What other CL tools for making jack
connections in an *easy* way are there?