Oliver, That does clear things up a bit, even if it is quite a bit to take in...
Previous to applying the realtime-lsm patches, audio recording/playback with multi-track hard disk recorders such as Ardour was very laggy and the audio skipped with more than 3 or so tracks. After I installed the new kernel, however, I have benchmarked it to around 20-odd tracks simultaneously playing audio and there was no skipping or patchyness. I assumed before your explanation that the realtime-lsm patch simply enabled faster access to studio-specific audio hardware (such as my Delta 1010 PCI card/outboard). It is apparently though different from the Preempt patches... I think the reason I thought they were related is in the kernel configuration (I used menuconfig), under the "Kernel Pre-emption" section was "No pre-emption", a couple of others (cant remember off my head) and "Realtime Latency" :) James Oliver Korpilla <[EMAIL PROTECTED]> wrote : > [EMAIL PROTECTED] > schrieb: > > Is Realtime-lsm the same thing? I'm assuming no, as I have realtime-lsm > on > a 2.6.11 custom-built kernel for using a recording studio with... > > No, there is a mixup of name meanings here. > > Realtime priorities under Linux are priorities that are higher than that > of any other user process. Linux offers 99 levels of those. If a process > is elevated to such a high priority it will not have to compete for the > CPU with other, non-realtime processes, and is therefore mostly safe > from having to long pauses in playing back an audio file or recording one. > > LSM are the Linux Security Modules. This is a framework for fine-grained > security models (beyond the user-or-root model). Because elevating a > process to a RT prio needs root or acquiring a "capability" to > increase > a process' prio (only root usually can do that), there is this patch to > allow standard programs to elevate themselves without being run by root. > > BTW: This is useful for playing and recording audio, e.g., but > introduces a security risk by allowing normal processes to hog the CPU > and starve the system from resources. But normally that's not a problem > for you, except you have an 0wn3d user account (got "hacked" by some > > script kiddies) or have a very stupid application. > > "Real" realtime support like introduced with the preempt patches is > not > simply changing priorities. That stays the same. It enables you to > switch between processes faster if a more important process becomes > runnable. Usually all other processes must wait while one process > executes a system call like read() on a device or open() on a file or > whatever. With preempt the more important process only needs to wait if > the process is in a very critical section of the kernel code where it is > explicitly forbidden to be preempted. The preempt patch therefore lowers > the "average latency" (the time you have to wait for the most > important > process to execute) and allows smoother multimedia. > > Any questions left? Hope I didn't overwhelm you - it's a bit hard to > explain. > > With kind regards, > Oliver Korpilla > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] ___________________________________ Sent Using: Total Carnage WebMail, with NOCC, http://nocc.sourceforge.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]