[linux-audio-user] IRQ settings and low latency

[Mark Knecht]

On Thu, 2004-03-11 at 12:15, Greg Jednaszewski wrote:
> At the end, it talks about setting up IRQs such that the sound card is
> at a high priority relative to other devices in the system.  However,
> all the information in the doc pertains to non-APIC machines.  What
> about an APIC-enabled machine?
> 

Greg,
   Hi. On APIC enabled machines the story is somewhat different. OK,
it's totally different. I've poked around looking for info. I've gotten
pretty consistent answers, even if they are somewhat confusing. Clemens
and I had a discussion about this earlier. I think it's probably in the
archives if you want to go dig that up. 

   The short answer is that the IRQ number doesn't have anything to do
directly with interrupt priority on an APIC machine, but its vector
does.

   First, start with dmesg more or less immediately after a boot. You'll
find a big section that looks like this:

 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 000 00  1    0    0   0   0    0    0    00
 01 001 01  0    0    0   0   0    1    1    39
 02 001 01  0    0    0   0   0    1    1    31
 03 001 01  0    0    0   0   0    1    1    41
 04 001 01  0    0    0   0   0    1    1    49
 05 001 01  0    0    0   0   0    1    1    51
 06 001 01  0    0    0   0   0    1    1    59
 07 001 01  0    0    0   0   0    1    1    61
 08 001 01  0    0    0   0   0    1    1    69
 09 001 01  0    1    0   1   0    1    1    71
 0a 001 01  0    0    0   0   0    1    1    79
 0b 001 01  0    0    0   0   0    1    1    81
 0c 001 01  0    0    0   0   0    1    1    89
 0d 001 01  0    0    0   0   0    1    1    91
 0e 001 01  0    0    0   0   0    1    1    99
 0f 001 01  0    0    0   0   0    1    1    A1
 10 001 01  1    1    0   1   0    1    1    B9
 11 001 01  1    1    0   1   0    1    1    C1
 12 001 01  1    1    0   1   0    1    1    A9
 13 001 01  1    1    0   1   0    1    1    B1
 14 000 00  1    0    0   0   0    0    0    00
 15 001 01  1    1    0   1   0    1    1    C9
 16 001 01  1    1    0   1   0    1    1    D1
 17 000 00  1    0    0   0   0    0    0    00

The first column is the hex version of what's in the /cat
/proc/interrupts table, and the last column is the vector associated
with that interrupt. The priority, as I understand it, is driven by the
highest vector number. In the table above vector 'D1' is highest, so you
look back at it's IRQ number (16 hex) convert it to decimal (22) and
look it up in the /proc/interrupts table and find that in this machine
the VIA8233 has the highest priority, followed by USB, then the ICE1712,
the radeon, and so on.

mark at Wizard mark $ cat /proc/interrupts 
           CPU0       
  0:     308971    IO-APIC-edge  timer
  1:       1891    IO-APIC-edge  keyboard
  2:          0          XT-PIC  cascade
  8:          2    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 12:      40857    IO-APIC-edge  PS/2 Mouse
 14:      14236    IO-APIC-edge  ide0
 15:         12    IO-APIC-edge  ide1
 16:     195648   IO-APIC-level  radeon at PCI:1:0:0
 17:          0   IO-APIC-level  ICE1712
 18:       6785   IO-APIC-level  eth0
 21:       6124   IO-APIC-level  usb-uhci, usb-uhci, usb-uhci
 22:       9802   IO-APIC-level  VIA8233
NMI:          0 
LOC:     308929 
ERR:          0
MIS:          0
mark at Wizard mark $ 

*APPARENTLY* interrupts with no vector (like the system timer) are
either not handled by the APIC system, or are just higher priority than
those with vectors. This makes sense for IRQ0 which is the system timer,
and for IRQ14 where I have no device so a vector was not assigned.

Unfortunately I know of no method to tune the system interrupt
priorities other than move cards from slot to slot until you get
something acceptable. I would like to have my AP2496 (the ICE1712) as
the highest priority device in this box but I haven't managed to make
that happen yet. The 'right' way to do it is to have an app that would
rewrite the vector table, but no app like this exists today, at least in
the user space, as far as I know.

I hope this helps answer some of your questions, and truly hope I didn't
create more confusion.

With best regards,
Mark