On Wed, 21 Dec 2005 19:13:57 +0100 Christoph Eckert <ce@xxxxxxxxxxxx> wrote: > > 2. ?Use the realtime_lsm module on an existing kernel - > > I've tried this, but I read it's no longer supported in the kernel > > because of #3... > > It's still supported and I run it on top of a recent 2.6.14.2 kernel. > Advantage: it's realtively simple to build and use. Usually you do not > need to rebuild a complete kernel, you only need to build that module > and load it. > > OTOH, the RT-LSM module "only" makes it possible that non-root users get > access to realtime priviledges - it doesn't improve the latency of the > system itself, so... Well, rtlimits doesn't do this either. The mechanism to gain realtime privs and the worst case scheduling latencies of the kernel are two completely different issues. For the former, there's the realtime-lsm and rtlimits which _only_ enable a non root user to do what a root user could do anyways. For the latter, there's the -rt kernels, although the vanilla kernels are quite usable these days, too. > > 3. ?Use rtlimits, which is already a part of the default kernel. > > ...this is the right thing to do, I guess. Well, it would be if the distributions supported this mechanism via the usual PAM mechanism. As long as that is not given, a hack is needed, be it either the realtime lsm or set_rtlimits. > The default 2.6.14 kernel is much better for audio work than any kernel > before. If it is good enough for your work, why bother yourself with > kernel patching? It is quite ok for most uses, especially when not going for ultra low latencies (like 8 or 16 frames). Make sure you use the "(X) Preemptible Kernel (Low-Latency Desktop)" setting though when building a vanilla kernel (or make sure your distro builds it this way if you use a distro provided kernel; check i.e. /proc/config.gz and/or write a mail to the appropriate ML/maintainer). Also the -rt kernel, due to prioritizing the irq handler threads, provides better RT "guarantees" if you want to call it that ;) I.e. given that the scheduler works correct, and that you have setup the priorities in your system correctly (and that jackd ant the clients are well behaving RT programs), there's almost _no way_ that other system activity might cause delays that produce xruns in turn, even with ridiculously low latencies. Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org
