Florian Schmidt wrote: I went for Complete real-time on this build. How do I set jackd's priority? There is a link on the wiki about setting irq priorities, but it seems to be broken. How do I set these? and how do I set SCHED_FIFO for an irq handler? Thanks Florian. I'll try building with the Pre-emptible, low-latency desktop option today as well. -ERic Rz.

Rui Nuno Capela posted a nice rtirq script (for RT preempt) to the ccrma list. Read the thread to get it working in CCRMA, I have it currently working under gentoo if anyone i interested in that. http://ccrma-mail.stanford.edu/pipermail/planetccrma/2004-December/007283.h… m. On Sun, 16 Jan 2005 10:41:41 -0500, Eric Dantan Rzewnicki <eric(a)zhevny.com> wrote:

Jack O'Quin wrote: Thanks Jack. I'm still working with CONFIG_PREEMPT_RT for now. Current audiobox set up: http://zhevny.com/doc/audiobox_settup Current kernel config: http://zhevny.com/doc/config-2.6.11-rc1-rt-v0.7.35-01-audiobox-1 I set my IRQ handlers' priorities like this: p=99 ; for i in 1 9 11 8; do chrt -f -p $p $i; p=$(($p-1)); done where: IRQ 1 i8042 (keyboard) IRQ 9 ice1712 (delta66) IRQ 11 ymfpci (used only for midi IRQ 8 rtc (is setting prio for this necessary?) I set the prio for the rtc because the wiki says to turn off threads for it ... but, from what Florian said earlier that is only for desktop-preempt now. Since this kernel is realtime-preempt and all handlers are threaded, do I still need to treat the rtc specially? jackd starts fine like this: LD_ASSUME_KERNEL=2.4.22 jackd -v -R -P 90 -d alsa -d ice1712 -p 64 -n 2 no xruns except the expected ones on client connect/disconnect. Does it matter which version of 2.4 is assumed? I've seen .22 and .19 in various places. there are 5 jackd threads started. Only one has prio 90 as specified with -P. It and 2 others are SCHED_FIFO, but the 2 other are prio 99. How did they get that? The remaining 2 threads are SCHED_OTHER with prio 0. Is this expected behavior? I can run this script: http://zhevny.com/bin/ecamynthes/ecanoscl-i-0.0.2.sh which now starts ecasound like this: chrt -f -p 80 ecasound <various_options> and sets LD_ASSUME_KERNEL The script runs fine and connects to jack, but the audio it produces is very scratchy. This may have something to do with ecasound itself, though, since I upgraded that yesterday. Is it possible that the extra CPU overhead of preempt_rt is causing this? I'm guessing not since my box has >2GHz cpu, but maybe it isn't only about cpu power ... How significant is the extra overhead of preempt_rt compared to preempt_desktop? Let's see .... have I missed anything? I get >50MB/s for all my drives in hdparm -t tests. Any other low latency best_(guess)_practices I should be aware of? Thanks guys, Eric Rz.

On Sun, 2005-01-16 at 14:25, Eric Dantan Rzewnicki wrote: If you use 2.6.x + the lsm realtime module you need to use jackd, not jackstart. In newer versions (cvs) of jack jackstart works (it complains but works anyway). -- Fernando

Eric Dantan Rzewnicki &lt;eric(a)zhevny.com&gt; writes: Either is fine. It forces glibc to use the old-style kernel interfaces for threading, so it to uses linuxthreads instead of NPTL. Yes. The other two realtime threads are the JACK watchdog timer and the Linuxthreads manager thread. You should probably set LD_ASSUME_KERNEL consistently for all clients, but the `chrt' should not be necessary. JACK will set all the client process thread priorities to 89 (one less than 90), IIRC. You don't want to mess with the other ecasound threads. They'll just interfere. -- joq

Eric Dantan Rzewnicki &lt;eric(a)zhevny.com&gt; writes: It runs inside of ecasound, but is not the main thread. It will probably have an ID of 3766 or 3767 in your example. The `ps' output is screwy for threads. Try something like... $ ps -eo pid,tid,class,rtprio,ni,pri,comm | grep ecasound -- joq

On Sun, 16 Jan 2005 17:15:13 -0500 Eric Dantan Rzewnicki &lt;eric(a)zhevny.com&gt; wrote: The rtc prio only needs to be high when you use a software that needs the rtc. I think, some midi sequencers use it (used it), so i thought it doesn't hurt when i advise people to give it a high prio, too.. When it's not used, the high prio shouldn't have any negative effect either.. 90 is a bit high. jack also starts a watchdog thread with a prio +10. I'd recommend a prio of 60 or 70 for jackd. May i ask why you use the LD_ASSUME_KERNEL hack? Do you get bitten by the nptl-hell? Try running jackd without it and check the threads with chrt. I don't think so. But i'm not sure. I think for libc the only important thing is that it's a 2.4.x version and thus uses the linuxthreads implementation instead of nptl.. Has anyone done any statistics? Well, i run preempt_rt on a 1.2ghz athlon here and it works fine for audio stuff. I don't see any obvious performance differences. Flo -- Palimm Palimm! http://affenbande.org/~tapas/

On Sun, 16 Jan 2005 09:55:26 -0500 Eric Dantan Rzewnicki &lt;eric(a)zhevny.com&gt; wrote: like joq said, use the -P option. Hmm, "irq priorities" are something different from "irq handler priorities". The former refers to the priorities on the interrupt controller. Usually messing with these is not needed, especially on RP kernels, as the top level irq handler routines are very short. What we want to control is the priority of the bottom half irq handler which is doing the grunt work. For this, the chrt utility from the schedutils package is useful.. chrt -f -p 99 `pidof "IRQ 5"` for example, makes the bottom half irq handler for IRQ 5 run SCHED_FIFO with a priority of 99. Inspect the output of cat /proc/interrupts to see which irq number corresponds to which device.. Use chrt -p `pidof "IRQ 5"` to inspect the scheduler classes and priorities for irq's.. There's a tradeoff between low-latency desktop and fully preemptible. The latter should give even less xruns (when configured right) at the expense of some cpu overhead. Flo -- Palimm Palimm! http://affenbande.org/~tapas/