[linux-audio-user] Just bought a Delta 1010LT, now what..?

Mark Knecht mknecht at controlnet.com
Mon Sep 27 11:09:17 EDT 2004


Joe Hartley wrote:
> On Sat, 25 Sep 2004 15:47:25 -0400
> Lee Revell <rlrevell at joe-job.com> wrote:
> 
>>Actually, you should probably leave it alone.  The important thing is
>>not which IRQ it's on, it's more important that the IRQ not be shared. 
>>          [ snip ]
>>The interrupt priorities mentioned by the previous poster are not a big
>>deal here.  I believe these only determine which interrupt the CPU sees
>>first if they happen to fire at the *exact* same time. 
> 
> 
> I respectfully disagree; the IRQ is very important to the system!
> There's a ton of detail why at http://www.pcguide.com/ref/mbsys/res/irq/func.htm
> 
> It's worth noting that many motherboards have a way of assigning IRQs
> to particular slots in the BIOS.  That might be what you need to get IRQ 9
> assigned to the sound card.  If the 1010 is at 5, which is often used
> for the parallel port, just about every other peripheral will be ahead
> of it, taking precedence.
> 

Since I was one of the original folks bringing attention to this subject 
I'd like to try and clear up a couple of things, if possible, and if 
not, then make them a little muddier.

1) Interrupt priorities have been a problem since the days of DOS and 
slow computers. However Linux is not DOS, computers are much faster, and 
things probably work better today. That said, better does not generally 
mean perfect and some sound thinking on the part of the user is usually 
time well spent.

2) If someone is having consistent sound problems with their card is it 
almost certanly *not* an interrupt problem. Consistent sound problems 
are most generally wrong/bad drivers, bad levels, or something else 
which is hosed up way to much for interrupts to make a difference.

3) In a lightly loaded system with a good kernel a good sound card will 
probably run fine on any interrupt. (At least with higher latencies) 
After all, if there are no competing interrupts then your sound card is 
the first *active* interrupt. The hardware can certainly handle this easily.

4) Interrupt positioning makes the biggest difference for systems that 
experience an occasional problem. An occasional xrun can be difficult to 
track down. It might be caused by some other interrupt source delaying 
system access to the sound card, or possibly something else entirely. We 
don't know and probably will never know, so we adjust priorities in 
favor of the sound card since we don't know what else to do. In my 
experience this helps. (While this experience is mostly under Windows, I 
freely shared when we started talking about this topic. Take it for what 
it's worth.)

5) None of these numbers apply to APIC based systems, but I beleive the 
  *logic* of the problem still does. The processor can only work on one 
task at a time. Interrupts help direct the processor to work on a 
certain high-priority task. Adjusting your interrupts to make the sound 
card higher priority can only help. It can't hurt. That said it may not 
solve your problems. Unofrtunately today we seem to have no tools to 
optimize interrupts in APIC based systems. This is disapointing and I 
hope it will change some day.

In a perfect world adjusting priorities would be the last thing you'd 
do, and then only when somethign didn't work well. It would be nice to 
just plug the card in and have it work. However, they don't and it's 
very disappointing (to me anyway) to try using your system for a long 
period of time and then to have to tear it apart to move cards later on. 
I'd rather do it once. For this reason, and really only for this reason, 
I suggest trying to get your card on a 'good' interrupt early on as it 
saves you having to mess things up later. That said, if the rest of the 
system has problems then interrupt priorities won't fix those.

Don't know if this clarifies or obscures. Take it for what it's worth, 
or more reasonably, what you paid for it.

cheers,
Mark



More information about the Linux-audio-user mailing list