Re: [LAU] Re: difference between realtime-kernel and low-latency-kernel?

On Thursday 04 October 2007, Chuckk Hubbard wrote:

> > Well, with a vanilla kernel you simply don't get the fine grained control
> > over
> > what code gets the cpu at what times as with a realtime-preemption
> > kernel..
> >
> > It is true that for many people a vanilla kernel with CONFIG_PREEMPT and
> > CONFIG_HZ=1000 delivers great performance, probably even better than
> > a "lowlatency" 2.4.x kernel. But basically one badly behaving kernel
> > driver
> > might cause delay, so for differing people the results differ. With a -rt
> > kernel you would just give this device a nice and low prio, so it doesn't
> > even get a chance to disturb the soundcard/jack..
>
> I'm a big fan of my rt-patched kernel; I'm also a big fan of taking out
> most of the distro's default stuff from the kernel. One of these days I
> will compile an rt kernel with no network support even - my soundcard
> shares an IRQ with eth1, I don't know if this will help or not.
> But isn't it a nice and high prio? As in, the chrt prio? I understood
> this as different from the nice prio, no? I may not be doing it correctly.
> I set my soundcard IRQ to something like 70, jackd to something like 65,
> and Pd to something like 60. The Pd GUI I set a little lower yet. Do I
> also have to renice these apps?

Well forget the word "nice" in that sentence. It has nothing to do with nice
levels :) Nice levels are only relevant for SCHED_OTHER processes. Anyways,
if your e.g. hd controller device disturbs your audio device make sure you
give the audio device a high prio and the controller device a low prio. That
was what i meant..

And yes, i consider it a bug that top and other software report the SCHED_FIFO
prio as negative values. Where does that come from? Does the prio already get
listed as negative in /proc? Or do they simply do it to separate the
SCHED_FIFO threads from SCHED_OTHER threads? Anyways POSIX speaks of positive
SCHED_FIFO prios in the range 1..99 afaik..

> I get visible xruns but not audible so far. I am guessing I have the wrong
> buffer sizes between Pd, Csound, and jackd...

No, i don't think so. If you use Pd and CSound as jack apps, then jack tells
them what buffer size to use. If one of these used the wrong size you would
definitely hear it..

Start jack and run this script and tell us the output please:

http://tapas.affenbande.org/rt-setup-report.sh

Thanks,
Flo

-- 
Palimm Palimm!
http://tapas.affenbande.org
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user