[LAU] Regular Xruns?
jamesmstone at gmail.com
Fri Aug 7 06:50:33 EDT 2009
Thanks for the extra suggestions, but still no further:
James Cameron wrote:
> On Fri, Aug 07, 2009 at 09:09:56AM +0100, James Stone wrote:
>> uname -a
>> Linux 2.6.29 #1 SMP PREEMPT RT Fri Aug 7 02:24:17 BST 2009 i686 GNU/Linux
>> cat /proc/interrupts
>> ERR: 6
> That ERR is interesting. Does the xrun correspond to increments of ERR?
No, ERR stays constant at 6
>> ~/jack_stuff$ ./irq_check 5
>> pid 2106's current scheduling policy: SCHED_FIFO
>> pid 2106's current scheduling priority: 99
> One of the things that increased priority on an IRQ doesn't do is
> prevent other drivers from hogging the CPU during an interrupt. All
> drivers that handle interrupts can be a cause, if they contain coding
> flaws. If you can remove all drivers you don't need, reducing the
> /proc/interrupts list of drivers to a bare minimum, you can effectively
> exclude some of the problem space.
>> # "open up" the PCI bus by allowing fairly long bursts for
>> all devices, increasing performance
>> setpci -v -s "*:*.*" latency_timer=b0
> Does the problem happen without this line?
Yes. This has no effect on the problem.
>> But still get xruns every 14 mins!!!
> Fascinating. This will make it easier to diagnose if it happens so
> regularly. Things I think you should try:
> 1. be in a text console (chvt 1) at the time of one of the expected
> events, and see if it still occurs ... this is so that you can exclude
> interrupts from your graphics adaptor as being a contributor, since I
> note that there are many interrupts counted on IRQ 10, which is shared
> between USB and Nvidia.
Yes - it still happens.
> 2. disconnect all unnecessary USB devices, see if the problem goes
> away, since I note that there are many USB interrupts counted on IRQ 10
> and 11, ... you might even go so far as disconnecting a USB keyboard and
> mouse for the time of one of the expected events.
All usb devices removed and xrun still occurs.
> 3. look for cron events around that time, e.g. by reading the cron
> configuration files, or brute force using "strace -o cron -p `pgrep
> cron`", to see if the overrun is contributed to by scheduled activity.
I stopped cron, and it still happens.......
I'm wondering if it could be some problem with the sound card itself...
It is around 9 years old now! Will try with the on-board sound to see if
More information about the Linux-audio-user