On 10/4/07, Florian Schmidt <mista.tapas@email-addr-hidden> 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?
This goes as far that if one sees an xrun while running a properly
> setup -rt-kernel one knows it's an application bug or a soundcard driver
> bug ;) The kernel itself or any userland processes (X, cronjobs, whatever)
> as
> a source of timing problems are pretty much eliminated.
I get visible xruns but not audible so far. I am guessing I have the wrong
buffer sizes between Pd, Csound, and jackd...
-Chuckk
-- http://www.badmuthahubbard.com
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
Received on Thu Oct 4 12:15:01 2007
This archive was generated by hypermail 2.1.8 : Thu Oct 04 2007 - 12:15:01 EEST