[linux-audio-user] realtime-preempt-2.6.11-rc1-V0.7.35-01

[Florian Schmidt]

On Sun, 16 Jan 2005 09:55:26 -0500
Eric Dantan Rzewnicki <eric at zhevny.com> wrote:

> > In the former case, just making all irq handlers threaded except for the
> > soundcard irq handler should give pretty good results already (also run
> > jack at a prio of 60 or 70 in this case). For this the "threaded irq
> > handlers" section on the page you quoted should be accurate. 
> 
> How do I set jackd's priority?

like joq said, use the -P option.

> 
> > In the latter case all irq handlers are threaded by design, so in this
> > case you need to make sure that our soundcard irq is the highest prio
> > irq handler in the system. Make the soundcard irq handler sched_fifo
> > with prio 98 instead of unthreading it. I always have the keyboard irq
> > handler at prio 99, so magic sysrq works even in the worst cases (i
> > haven't seen negative effects on jack operation yet).
> 
> 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?

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..

> 
> > The other /proc and /sys stuff is mostly important for debugging. 
> > Also when in doubt consult the help texts of the kernel configuration
> > options.. They should have the relevant info, too.
> 
> Thanks Florian.
> 
> I'll try building with the Pre-emptible, low-latency desktop option 
> today as well.

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/