On 10/4/07, Florian Schmidt <mista.tapas@gmx.net> 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