10 Mar
2008
10 Mar
'08
9:30 p.m.
On Mon, Mar 10, 2008 at 4:36 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Mon, 2008-03-10 at 19:53 +0000, James Stone
wrote:
Paul, you're absolutely right. I encountered this exact issue years
ago with the open source Via Unichrome driver, and fortunately was
able to get it fixed by the developers. Typically the (userspace X11)
video driver tries to write to the card's command FIFO without first
checking whether it is full. If the FIFO is full, this will
completely stall the PCI bus until the FIFO drains. Nothing at all to
do with interrupts.
This is done by vendors to get better benchmark scores. You can also
prove that this is your issue by running a simple userspace latency
tester that does not touch the audio hardware; it will also report
large delays when moving windows around.
If this is your problem, your only hope is to use the open source
driver for your video hardware, and if that driver has the same
problem, to report it to the maintainers.
I'd still like to see if disabling the VSYNC interrupt changes things,
if only to disprove the common perception that the problem is caused
by interrupt sharing.
Lee
Yes. but IRQ tuning is not much use with the
video on the same
interrupt as the sound card. Basically whenever a widget moves,
sound dropout occurs.
this is not how video display works. they are a lot like audio
interfaces actually. periodically, they interrupt the host CPU to say
"i'm about to start redrawing the screen from the framebuffer you last
told me about". that's about it really. they never redraw the screen at
any other time.
when your GUI toolkit decides to redraw a widget, it doesn't interact
with the h/w. all that happens is that eventually the new image of the
screen gets into the framebuffer, and on the next "VSYNC" cycle, the
video card will push it out to the actual display.
what is an issue is that the drivers and/or h/w associated with the
video card sometimes do not play fair with the PCI bus - they claim
owernship over it for too long while doing a redraw, and this *does*
lead to xruns at low latencies.