[LAU] Regular Xruns?

[James Stone]

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.
> 
>>       start)
>>             # "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 
any improvement.

James