[LAT] rtlimits (was: a working rt-kernel -- please test )

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: krgn <k.gebbert@...>
Cc: <linux-audio-tuning@...>
Date: Friday, August 8, 2008 - 2:06 pm

Hash: SHA1

krgn wrote:

maybe, maybe not. it depends on compiler flags. That may be a question
for gcc specialists on the linux-rt-user mailing list.

I start to think we're chasing two independent but related bugs:
/something/ inside the kernel is triggered by invalid user setup. eg.
RT-priority inversion.

> On Thu, Aug 7, 2008 at 11:56 PM, krgn wrote:

i use

@audio - rtprio 90
@audio - nice -5
@audio - memlock 1400000

The man page says memlock's unit is KB not bytes.
IIRC someone said it's actually pages, but I did not check the source.

>> What values do people use, and why? Are these sane values?

I think so.

rtprio ranges from 1 to 99 and it does not matter how big the difference
is; as long as a value is larger it will "win" against lower values -
for SCHED_FIFO that is. - many suggest to leave a little "headroom"; it
does not need to be 99.

>> What are the rtirq settings that are

100 > timer-prio > sound-card-prio > jackd-process prio > 0

with a UA-25 on USB I use:

rtirq: reset [softirq-timer] pid=6 prio=1: OK.
rtirq: reset [softirq-timer] pid=11161 prio=1: OK.
rtirq: start [softirq-timer] pid=6 prio=99: OK.
rtirq: start [softirq-timer] pid=11161 prio=99: OK.
rtirq: start [rtc] irq=8 pid=2397 prio=90: OK.
rtirq: start [uhci_hcd:usb3] irq=22 pid=1066 prio=89: OK.
rtirq: start [i8042] irq=1 pid=330 prio=87: OK.
rtirq: start [i8042] irq=12 pid=329 prio=86: OK.

and run /usr/bin/jackd -R -P70 ...

@audio /usr/bin/jackd nice=-1 rtprio=85
@audio /usr/bin/qjackctl nice=-1 rtprio=84
@audio /usr/bin/ardour nice=-1 rtprio=83
@audio /usr/bin/hydrogen nice=-1 rtprio=82

as found on

is IMHO nonsense - in fact wrong: ONLY the jack-realtime callback should
have elevated priority. The audio-process-callback of the applications
will inherit this priority.
The above example would prefer GUI or JACK-stdio/log over disk-I/O.

There are use-cases where you may want to give an older-RTC-based
MIDI-application realtime priority. JACK-midi solves that for good.

>> For now, I switched it off,

makes sense to debug&trace.

>> yet I can see how it could be

now it clicked in the back of my head: there was something like
subtracting or adding 10 from the rt-priority in qjackctl, or jackd.
just a shot in the dark: jackd itself starts a couple of threads with
different priorities. I never cared since it just worked (and still does
on 2.6.24-rt3). - later today I'll be looking at jackd.

Meanwhile, does anyone here know about changes in the scheduler,
priority inversion etc of 2.6.26 ?

For high-level tests it may be interesting if a 2.6.26-rtX would run
stable if it does not do any audio or RT at all - just to double-back.
same without ACPI. for all we know this could well be caused by the
keyboard or some tty driver, no? I wish I had more machines to test ;)

puh, sorry for another long email - i got carried away.

Version: GnuPG v1.4.9 (GNU/Linux)

Linux-audio-tuning mailing list

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [LAT] build ALSA debian way, Jaromír Mikeš, (Tue Oct 7, 11:03 am)
[LAT] rtlimits (was: a working rt-kernel -- please test ), Robin Gareus, (Fri Aug 8, 2:06 pm)