Hi Florian.<br>
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.<br><br>
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?<br>
<br>
Thanks.<br>
-Chuckk<br><br><div><span class="gmail_quote">On 10/4/07, <b class="gmail_sendername">Florian Schmidt</b> <<a href="mailto:mista.tapas@gmx.net">mista.tapas@gmx.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thursday 04 October 2007, Chuckk Hubbard wrote:<br><br>> > Well, with a vanilla kernel you simply don't get the fine grained control<br>> > over<br>> > what code gets the cpu at what times as with a realtime-preemption
<br>> > kernel..<br>> ><br>> > It is true that for many people a vanilla kernel with CONFIG_PREEMPT and<br>> > CONFIG_HZ=1000 delivers great performance, probably even better than<br>> > a "lowlatency"
2.4.x kernel. But basically one badly behaving kernel<br>> > driver<br>> > might cause delay, so for differing people the results differ. With a -rt<br>> > kernel you would just give this device a nice and low prio, so it doesn't
<br>> > even get a chance to disturb the soundcard/jack..<br>><br>> I'm a big fan of my rt-patched kernel; I'm also a big fan of taking out<br>> most of the distro's default stuff from the kernel. One of these days I
<br>> will compile an rt kernel with no network support even - my soundcard<br>> shares an IRQ with eth1, I don't know if this will help or not.<br>> But isn't it a nice and high prio? As in, the chrt prio? I understood
<br>> this as different from the nice prio, no? I may not be doing it correctly.<br>> I set my soundcard IRQ to something like 70, jackd to something like 65,<br>> and Pd to something like 60. The Pd GUI I set a little lower yet. Do I
<br>> also have to renice these apps?<br><br>Well forget the word "nice" in that sentence. It has nothing to do with nice<br>levels :) Nice levels are only relevant for SCHED_OTHER processes. Anyways,<br>if your
e.g. hd controller device disturbs your audio device make sure you<br>give the audio device a high prio and the controller device a low prio. That<br>was what i meant..<br><br>And yes, i consider it a bug that top and other software report the SCHED_FIFO
<br>prio as negative values. Where does that come from? Does the prio already get<br>listed as negative in /proc? Or do they simply do it to separate the<br>SCHED_FIFO threads from SCHED_OTHER threads? Anyways POSIX speaks of positive
<br>SCHED_FIFO prios in the range 1..99 afaik..<br><br>> I get visible xruns but not audible so far. I am guessing I have the wrong<br>> buffer sizes between Pd, Csound, and jackd...<br><br>No, i don't think so. If you use Pd and CSound as jack apps, then jack tells
<br>them what buffer size to use. If one of these used the wrong size you would<br>definitely hear it..<br><br>Start jack and run this script and tell us the output please:<br><br><a href="http://tapas.affenbande.org/rt-setup-report.sh">
http://tapas.affenbande.org/rt-setup-report.sh</a><br><br>Thanks,<br>Flo<br><br>--<br>Palimm Palimm!<br><a href="http://tapas.affenbande.org">http://tapas.affenbande.org</a><br></blockquote></div><br><br clear="all"><br>--
<br><a href="http://www.badmuthahubbard.com">http://www.badmuthahubbard.com</a>