>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
