Re: rtirq usage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Sep 05, 2009 at 10:05:04AM +1000, Patrick Shirkey wrote:
> Thanks for taking some time to consider this.

Heh.  It's been my speciality for ten years on enterprise systems, where
the configuration of everything is carefully controlled.

> The wifi device is connecting via pcie.
> 
> It turns out that to get the xruns to a minimum it's necessary to
> run jack at rtprio 89.

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.

-- 
James Cameron
http://quozl.linux.org.au/
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux