Paul what you described is very unfortunate. Although I have not had time to perform any tests lately, I always had the bad feeling that the out-of-process model would cost us some performance because the kernel would screw us in some way. 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 a software implementation of a MIDI instrument that ideally should as be as good as the hardware counterparts in terms of playability. Regarding the sampler we are currently solving other basic design problems so for now I think we can let this issue aside since we will probably perform the first tests with direct ALSA/OSS output and standard out-of-process JACK mode (in the latter case not expecting to get extremely low latencies), but in order to get latencies at par with ALSA , when using JACK the in-process model is as you said probably mandatory. (and according to Steve Harris JACK would need some extensions to handle the loading of these in-process jack "plugins" at run time). For now we will probably test the extremely low latency cases using direct audio output otherwise it would be hard to isolate timing problems. (Was the deadline miss due to the sampler or due to jack not getting scheduled in time ? -> double frustration :-) ).
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 ? This would be really useful for those that need these extremely low latencies while at the same time being able to access to a fully fledged virtual studio where your only limitation is the CPU speed and RAM/disk speed/size. cheers, Benno Paul Davis wrote: > the JACK data i provided covers an out-of-process client. the > all-in-process client case has the same latency as ALSA only. > > the difference between the two is that although 99.9% of the time, the > kernel operates as desired and JACK can provide ALSA-only/in-process > performance in the out-of-process case, every once in a few tens of > thousands of process() cycles, the kernel messes up our scheduling and > this causes an xrun. tracking this down is an important but very, very > difficult case. its possible that it may never be solved. > > --p -- http://linuxsampler.sourceforge.net Building a professional grade software sampler for Linux. Please help us designing and developing it.
