Le Sun, 13 Aug 2006 13:51:50 +0200, Florian Paul Schmidt <[EMAIL PROTECTED]> a écrit :
> On Sun, 13 Aug 2006 12:46:35 +0200 > Dominique Michel <[EMAIL PROTECTED]> wrote: > > > A rt kernel will be of almost no use if you don't fix the priorities. > > You can use PAM-rlimits or the realtime-lsm module for that, and you > > have to be in the audio group. > > > > The audio group will have a higher priority and this is the right way > > to do that. > > > > You can take a lock at > > http://demudi.agnula.org/wiki/Low-latencyKernelBuildingHowto#Realtimescheduling > > > > PAM-rlimits is the new way of doing that, but if you want an very > > low latency for intensive audio work as synthesis or filter, the > > realtime.lsm will be better. > > There's no difference wrt to achievable latencies regarding lsm and pam. > Both are just ways to grant non root users SCHED_FIFO priorities for > their tasks. > From http://www.jacklab.net/phpBB2/viewtopic.php?t=103 : "Model 1: " Want to start a synth from time to time" SUSE Standard kernel with PAM from Rui (also available in the jacklab repository) Model 2 "Want to work with MusE or Rosegarden from time to time" JAD kernel and PAM (Because the SUSE Standard Kernel have no midi RT tick for sequencers) Model 3 " I want make some fat production / live performing with many native FX and soundgenerators with less then 10ms audiolatency" JAD Kernel and RT-LSM (WARNING: RT-LSM can maybe crash your system)" It is other websites that say exactly the same. I have done some test too. The result was a better (lower) latency with the rt-lsm. The difference was not big, but it was a difference, and it was a few xruns with PAM-rlimits already with 20% processor use when it was no xrun with the rt-lsm, the same jackd setting and the same running programs and processor use. Another issue is at I was a few times in trouble with the PAM-rlimits feature that kill any application that is doing a very high processor use. So, I definitely prefer the realtime-lsm. > > A very important issue with a rt kernel is at you must not have shared > > IRQ with a such kernel. You can check it with > > # cat /proc/interrupts > > It is specially important for the sound and the video card. > > http://ardour.org/system_requirements > > This is also not true stated like that. It is very well possible to have > shared IRQ's in a -rt system. Usually one doesn't want to have one's > soundcard IRQ shared though, because then the other device driver [and > irq handler] runs at the same prio potentially causing delays for out > soundcard. > If I share the same hardware IRQ with my soud card and another hardware, my whole system just hang from time to time, and that both with the PIC and with the APIC irq interface. The same append with the video card. And that with Demudi, gentoo with my own rt-kernel or with the audio pro rt-kernel, and before with Suse and a rt-kernel. I have to go in the Bios to reassign the IRQ and/or move the cards from slot to slot in order to solve this. > > > > If you are new with rt-kernel, I would recommend you to install an > > audio distribution as Demudi, planet CCRMA, jacklab, musix, or the > > gentoo audio pro overlay. They all have that rt stuff trimmed for you. > > > > With usb audio card, the IRQ period of the USB bus is 1 msec. That > > mean at you must use something as 48KHz 3 periods with jack (That will > > be a multiple of that irq period) in order to get a low > > latency with such sound cards. > > > And you MUST NOT be root in all cases with a rt-kernel. > > This is also not true. Of course it is possible to run your stuff as > root with a -rt kernel. This also saves you the hassle of setting up > either the realtime lsm or pam. It is why I recommend the use of an audio distribution for a new user of a rt kernel. > But it is not recommended as running > user stuff as root is often a security risk. And programs as bristol will just hang the whole system when running as root or suid root with a rt-kernel. It is one of the advantage of a rt-kernel: you can run jack with rt priority as normal user (in the audio group), and it is the right way to use such a kernel. Cheers, Dominique > > Flo >
