Last Saturday 17 July 2004 12:33, Malcolm Baldridge was like: > > I have my soundcard (an onboard i8x0) sharing an interrupt (IRQ 11) with > > eth0 and usb-uhci. Would this be likely to give rise to xruns in a > > similar way? > > I think motherboard audio bugs/latency issues will be more of a problem > than shared IRQs. Turning off the PnP Setting in the BIOS and then "Reset > Configuration Data" may cause a re-assignment to occur during the next time > you go through BIOS POST. It's worth a try. > Moving the ethernet card should get you another IRQ, though keep in mind, > it's a bit stranger with PCI than ISA. To make it even spicier, some PCI > slots are not capable of bus-mastering DMA. But the answer to your > question is yes: moving the card will get you a different IRQ. Great, thanks. > As for the onboard-USB, well, that might be harder to "move". The problem > is that the IRQs are "mapped" to PCI INT-levels, and it seems that many > system hardware designers get very lazy and slopping with how they use > them. Last Saturday 17 July 2004 13:26, Jan Depner was like: > ????????In addition to the time to determine interrupt source there is > another problem with shared interrupts - don't use any USB devices or run > your network while trying to record. My suspicions were correct then, I don't use USB at the moment, so I'll see if I can turn it off in the BIOS. Back to Malcolm: > Shared IRQs have been with us for a few years now, and I doubt it's the > source of most xruns people see on their systems these days. We are > talking about microseconds of additional time to determine the interrupt > source here. If your xruns are in the hundreds of milliseconds, this is > not your problem. If you're on the borderlines, THEN it might be something > worth looking into. Actually, I think I'm doing fairly well compared to similar systems, I _can_ run JAMin (just, but with good results), so I'm probably being a bit picky. > This brings up a point about technical diagnostics and troubleshooting: try > to assess the magnitude of your xruns to give you valuable hints as to > where to look for what might be wrong. If they're in the hundreds of > milliseconds, your problem is most likely a > big-kernel-lock/preemptible-kernel related fault, or just really bad > hardware. File system choices affect this as well. I don't think I have anything majorly wrong, I'm just checking if there is anything I've overlooked as I still think I could improve on my system's current performance. Thanks for the advice, I think this could be quite a worthwhile exercise. tim hall
