Re: [linux-audio-user] How do I increase IRQ priority

From: Spec <specialaka@email-addr-hidden>
Date: Fri Mar 04 2005 - 21:48:16 EET

>Are this about the rtirq (lowercase) script on planetccrma? I was the
>original author of those bits and it is intended to generically prioritize
>those IRQ thread handlers on a realtime-preemptible kernel (PREEMPT_RT).

yes, I think it is, thanks for your reply dude! I'm using CCRMA on top of original FC3 using apt-get Nice.

>If this makes sense to you, just check the output of the command:
> /etc/init.d/rtirq status
>and see how IRQ 14 and IRQ 15 is going among the others.

cool, I see now that IRQ number order is no longer the determining factor (if its RTPRIO that now determines priority as I am assuming)

  PID CLS RTPRIO NI PRI %CPU STAT COMMAND
  235 FF 80 - 120 0.0 S< IRQ 8
 1459 FF 70 - 110 0.0 S< IRQ 22
 1594 FF 70 - 110 3.4 S< IRQ 17
 1752 FF 60 - 100 0.1 S< IRQ 21
  334 FF 50 - 90 0.0 S< IRQ 1
   20 FF 49 - 89 0.0 S< IRQ 9
  294 FF 47 - 87 0.0 S< IRQ 14
  297 FF 46 - 86 0.0 S< IRQ 15
 1269 FF 44 - 84 0.0 S< IRQ 6
 2132 FF 40 - 80 0.4 S< IRQ 16
 2545 FF 39 - 79 0.0 S< IRQ 4
 2546 FF 38 - 78 0.0 S< IRQ 3
 2575 FF 37 - 77 0.0 S< IRQ 7
 3005 FF 36 - 76 0.0 S< IRQ 23

so HD not really doing much %CPU 0.0, ICE1712 3.4 then AGP 0.4 then USB 0.1 (mouse) most used,

also theres a few IRQ values here not listed in /proc/interrupts i.e. 6 4 and 3 ?

perhaps its just points where bus just overloaded periodically with HD and AGP and mouse on USB (plus ethernet and firewall running)

by doubling RTPRI of ICE compared to HD i.e. put HD at bottom of priority list i.e. IRQ 14 and 15 RTPRIO 36 or 35 (has it got enough caching to cope with that?, how do I increase disk caching (plenty of memory free 100+mb easy) on FC3 with 2 disks merged to one LVM volume?) would that do the trick do you think?

also there is the option of IDE busmaster on/off in the bios, now IRQ's have moved to software is that even relevant? if so whats best? currently off. but was causing XRUN with it on as well.

Is an XRUN fatal, i.e. does it indicate lost samples.

CPU load doesnt seem to go over 20% so shouldnt be a problem there.... but not an accurate profile available.

are there any good system profilers that will show what process was using cpu/irq at which time?

Sorry, still a lot to learn, particularly as they keep adding things (nice things... but...) to RedHat/Fedora/Kernel/etc.

another thing I just thought of is jack prefers 32 bit samples, option to fall back to 16 bit, but... if hardware is 24bit, why pass around an extra 33% data which on multitrack audio soon adds up particularly at 96kHz. or loose 8 bits fidelity at 16 bit. Be nice if jackd would support 24 bit, maybe it does somehow.
Received on Sat Mar 5 00:15:09 2005

This archive was generated by hypermail 2.1.8 : Sat Mar 05 2005 - 00:15:10 EET