On 09/03/2009 12:59 PM, Louis Gorenfeld wrote: Thanks. That command is very useful. I see this result. Sound card is irq 16 and wifi is irq 17. Does it mean the wifi card has a higher prio than the sound card? CMD RTPRIO [IRQ-16] - [IRQ-17] 50 > On Wed, Sep 2, 2009 at 7:47 PM, Patrick > Shirkey<pshirkey(a)boosthardware.com> wrote: > >> Hi, >> >> >> If I'm running rtirq from /usr/src/rtirq folder will it pick up the conf >> file in the same folder or does it have to be in the /etc/ folder? >> >> Also how can I check the existing irq prios for the devices prior and >> after running the script? >> >>

Hi Patrick, The IRQ number I don't believe has to do with priority much anymore. What you want to be higher is the RTPRIO number. It looks like neither of these are really prioritized... I remember rtirq being pretty smart and being able to automatically grep for your sound card IRQ and adjust the rt priority.. in this result, have you already run rtirq? Louis

_______________________________________________ Linux-audio-user mailing list Linux-audio-user(a)lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

On Thu, Sep 03, 2009 at 04:06:29PM +1000, Patrick Shirkey wrote: /me handwaves It implies a larger than before amount of time being spent inside the driver for either the wifi device or the video device. The extra time or the temporary disabling of interrupts within that driver might be affecting the delivery and processing of interrupts for the other two devices.

Consider how the wifi device is communicating with the CPU. Is it via PCI or USB? If USB, then the type of USB controller becomes interesting. You may have a controller that meets multiple specifications, and if so you may get different results by manually choosing the controller driver. Controller is often called host. Look at your modules installed. Scan for modules with names ending in hcd. Test them one at a time. That is to say, remove all USB devices except the offending device, remove (rmmod) all of the -hcd modules, then manually insert one at a time from this set: ehci-hcd.ko isp116x-hcd.ko ohci-hcd.ko r8a66597-hcd.ko sl811-hcd.ko u132-hcd.ko uhci-hcd.ko ... to find which ones work with the hardware and the device (using lsusb), then compare your findings against what was originally installed.

On Sat, Sep 05, 2009 at 10:05:04AM +1000, Patrick Shirkey wrote: Heh. It's been my speciality for ten years on enterprise systems, where the configuration of everything is carefully controlled. It would be normal to assume that increasing jack's real-time priority may cause jack to respond to events sooner. On the other hand, what this might be doing is changing the timing of events associated with the wifi device. You may have found a sweet spot. It can be a very complex cause chain, and it is very difficult to figure out what is actually causing it. While using jack, a sound device, a wireless device, and a graphics driver, the events come thick and fast, and the order in which they occur could easily change the symptom. Is there network activity on the wifi device at the time? Activity such as transmitting packets can cause interrupts to be delivered. Activity such as receipt of beacons from another radio can cause interrupts as well. Both these interrupt sources will be counted in /proc/interrupts. Is the wifi device acting as an access point, or a client? As an access point the activity level is quite different ... it has to provide the beacons, which might not require an interrupt, but if it hears back from another radio it may have been configured by the driver to interrupt. Is the driver for the wifi device well known and considered stable? Is the graphics device on PCIe as well, or on a higher priority bus? A graphics device can preempt the CPU for access to memory during either video output (shared model) or during DMA. My gut feel is that there is a pathological interaction between the drivers and the devices. But this might only occur in your particular system. Best thing at this stage is to prod at it and see what happens, gathering behavioural problem data, and checking for known bugs in each driver. Or excluding the devices or drivers that are triggering the symptom. jack xruns are basically that the system could not keep up with the data flow demand ... but this says nothing about what the system is capable of if configured correctly by the drivers.