6 Oct
2007
6 Oct
'07
10:15 a.m.
Hi Florian.
I understood nice to be an adjective, but I was questioning the word "low";
I see now you were referring to non-audio, so I understand.
I have two jackd scripts I use, one for Playback-only, and one for duplex
using my Zoom H4 mic. I have attached the scripts and their outputs from
your script. See anything I could improve?
Thanks.
-Chuckk
On 10/4/07, Florian Schmidt <mista.tapas(a)gmx.net> wrote:
On Thursday 04 October 2007, Chuckk Hubbard wrote:
correctly.
--
http://www.badmuthahubbard.com
> 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 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