Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15

On Wed, 22 Jan 2003, Kjetil S. Matheussen wrote: First of all, I must say I have nothing against k_jack. I don't think I fully understand the motives (or the mechanims or design features that enable better performance), but as Ron Kuper wrote today, competition is good. I don't think it's fair to expect commercial companies to deal with competition from FOSS groups, while not welcoming competition from other FOSS developers. ;) And yes, there are performance problems with JACK in certain use scenarios: 1. Running with root privileges (and -R) but with a standard kernel (no low-latency or preemption patches). In RT-mode jackd doesn't tolerate client failures. But if you don't have a low-latency kernel, you will get 50-100ms stalls during normal use. In other words, running jackd with period size less than 50-100ms (-p 2048 => 46ms at 44100Hz) _WILL_NOT_ work reliably. Solution1 => Patch the kernel. Solution2 => Increase period size (-p 1024 or higher). Solution3 => Increase period count (-n 4 or higher) and run without root privileges. 2. Running complex setups without root privileges (and -R). If you have X clients participating in one JACK setup, those X clients have to get the CPU during each engine cycle. Without root privileges (and SCHED_FIFO scheduling policy), there's no magic that makes sure that all clients get enough CPU time. So the more the processes you have, the larger the chance of a client failure. Solution1 => Increase the period size or period count. These _HAVE_ to be notably higher than with single-thread audio apps. Solution2 => Run as root (see previous problem scenario). Solution3 => Patch the kernel and run as root. What does "cat /proc/asound/card0/pcm0[cp]/sub0/[hs]w_params" output while you are running k_jack? This information should help us understand the benefits of k_jack over current jackd. -- http://www.eca.cx Audio software for Linux!