linuxaudio.org

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
krgn wrote:

quoted text
> one or 2 quick addedums:

>

> ubuntu hardy kernel works great for me. it is presumably compiled with a

> different version of gcc, 4.2.3. could this be the source of the problems?

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:

quoted text
>

>> I did test with a few other versions of config, patchset and kernel sources

>> but keep running into problems. I can't seem to be able to produce something

>> that works reliably, all of the kernels run around 30 to 45 minutes with

>> around 65 - 70% load on jackd and then hard lock. Since this machine I am

>> using is pretty new, and I am havn't really run rt-linux on this one

>> extensivly yet (partly because its almost not necessary with current stock

>> debian kernels anymore), it could be something about the hardware, although

>> it seems unlikely. Its a T61 T5500 with 1G Ram fwiw. With this in mind I

>> think I should ask for some advice on what people consider sane values for

>> important scripts, pam etc. My /etc/security/limits.conf looks like this:

>>

>> @audio - rtprio 99

>> @audio - nice -15

>> @audio - memlock 1024000000

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

quoted text
>> considered safe? 

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

http://proaudio.tuxfamily.org/wiki/index.php?title=Howto_RT_Kernel
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

quoted text
>> useful/necessary for certain setups, and don't want to rule it out

>> completely. I start jackd oh hw:1 (hdsp multiface) with the following

>> parameters:

>>

>> /usr/bin/jackd -R -P89 -m -dalsa -dhw:1 -r48000 -p128 -n2 -Xseq

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.
robin

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkicUs4ACgkQeVUk8U+VK0LcGwCgwR6VIOLUN7YUGvS/0vEPpn+Q

PNkAnR+c2CeekQUK89S65FTtIeAqB1BU

=ZidW

-----END PGP SIGNATURE-----

_______________________________________________

Linux-audio-tuning mailing list

Linux-audio-tuning@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-tuning