As said, two years ago I was able to achieve 2.1msec
latency with the
LinuxSampler proof-of-concept code and I think for many low-latency
fetishists (a drummer playing a midi drumkit) it would be hard to give
up these excellent response times especially since we are talking about
JACK can still provide these response times. It just cannot guarantee
them for cases involving out-of-process clients on 2.4.X.
For now we will probably test the extremely low latency
cases using
direct audio output otherwise it would be hard to isolate timing
problems.
i think that would be a mistake. its actually much easier to isolate
timing problems with JACK because of the clean separation between the
different parts of the system. your sampler will contain no code that
seeks to control an audio interface.
(Was the deadline miss due to the sampler or due to
jack not getting
scheduled in time ? -> double frustration :-) ).
jackd always runs on time (other than when its basically impossible to
do so due to overwhelming system load). its the scheduling of the
clients that is a problem.
Paul, do you think that in (near) future it will be
possible to run
an entire virtual studio using jack's in-process model that runs
all active apps (eg ardour, sampler, snyth, FXes etc) as plugins
of a single process ?
its almost possible right now to do this, all that's missing is a
version of jack_client_open() that indicates that the client is
in-process. such a call exists, but its only for driver clients at the
moment.
however, i can guarantee you that it will be a long time or never that
ardour runs as an in-process client.
--p