Roger:

> When trying to push this machine to its limits, sharing IRQs
> gets to be a problem.  It would be so nice to be able to have
> the sound card have its IRQ different from the video and the
> Ethernet and all the other devices.  I'm thinking that there is
> a way to hard-code the IRQs that go with the PCI slots.  If
> I let it autoassign, I get a couple devices on IRQ9 and such
> and others seems empty and available.  I've checked the
> motherboard documents and it says don't do this unless you
> know what you are doing, but it doesn't tell you how either.
> The usual google search was not enlightening.

The manufacturer of the motherboard is responsible for putting the
necessary hardware on the motherboard/firmware/BIOS to let you
set & assign IRQ's manually.  For instance, the Phoenix BIOS that
comes with Dell desktop computers gives you absolutely no control
over what IRQ is in use by what device in the system.

I like motherboards made by FIC (www.fic.com.tw or www.fica.com ) - 
you can get them at some small retail computer stores.  There is
an electrical engineer at FIC who thinks it's important that the
user be able to manually mess with the interrupt settings, and I
for one agree with this.  (Out of the box it's set to "automagic"
mode for the general public though.)  The BIOS on the FIC mother-
boards I have is from Award.

You have some mis-conceptions about the way interrupts and IRQs
act, which I'd like to clear up for you.

First, the video card does not need an IRQ line, unless you are
running a DVD decoder, framegrabber, or some other specialized 
device.

If you have PCI cards, it is perfectly acceptable to have more
than one PCI card on the same IRQ.  The PCI bus uses level-sensitive
interrupts, and the PCI interrupt controller does the interrupt
steering for PCI INTA/INTB/INTC/INTD interrupts to the actual
motherboard/CPU IRQ lines.  It is perfectly acceptable to have
several PCI devices on the same IRQ, because each device has a
unique INT interrupt on the PCI bus.

The PCI interrupt controller will snag IRQ's from the motherboard,
depending on the PCI BIOS settings.  For instance, my company uses 
Toshiba laptops a lot for our field use.  The Toshiba BIOS sets
all PCI devices to the same IRQ.

ISA devices use the standard ISA bus edge-sensitive interrupts,
and each ISA device must be on its own IRQ.  So, the UART for an
ISA serial port controller would want to be on its own IRQ, and
no other device should be on that IRQ.  It's important to note that
you can have lots of devices in the system that have the hardware
configured for the same IRQ; however, the software device driver
for only one of those devices should be loaded at any one time.
Otherwise, you will get an IRQ conflict.  If you take care to un-
load the software device driver for, say, your serial ports, then
you could load the software device driver for, say, a sound card,
that uses the same IRQ as one of the serial ports.  The interrupt
handler in the kernel takes care of telling the processor what to
do if an interrupt is triggered, and provided you only have one
device driver trying to talk to the kernel interrupt handler for 
a given IRQ at any one time, you are in good shape.

> When I'm playing an mp3, if I also hit the system hard with
> an open-GL spectrum analyzer and have a large file
> moving across the (100mb) Ethernet, the sound garbles.
> Not a show-stopper, but I'm thinking its IRQ negotiaton.

This is most likely due to CPU utilization, and most likely
has nothing to do with interrupt conflicts.  What you would find
is that if you had an interrupt conflict, you would experience
deadlocked processes, runaway processes, or other apparent hardware
or system failures as you try to access the same IRQ from two diff-
erent device drivers.

MP3 decoding uses CPU time.  If you use the 'uptime' command or
the xload utility to view the load average for the system, you
would probably find that your sound will only garble under heavy 
CPU load.

Or, it could be that your disk is too slow for what you are trying
to do; i.e., the MP3 decoder most likely does not read the entire
MP3 at one time, but instead reads a few bytes into a buffer and
decodes them; when the buffer starts getting low, then it reads a
few more bytes into the buffer from the file.  If you are shoving
a large file onto or off of the same disk you have your MP3 on, then
it's possible that the disk was too busy handling this big file to
go back to where the MP3 was in a timely-enough manner.

> I wonder if the ($) OSS drivers would handle this better than
> the stuff bundled with the distros.  Or has anyone used ALSA
> for sound and can recommend it?

The stock kernel sound stuff has usually worked for me.  I tried
ALSA once but couldn't get ANYTHING to work in a timely manner so
I just gave up.  Generally I work on servers, routers etc. anyway
so sound is of tertiary (or lower) importance on such systems.

--
Jim Ockers (ockers@ockers.net)                     Ask me about Linux!
Contact info: please see http://www.ockers.net/

Fight Spam! Join CAUCE (Coalition Against Unsolicited Commercial Email)
at http://www.cauce.org/ .