[LAU] recommendations for usb sound card?

[James Stone]

On Mon, Mar 10, 2008 at 08:30:50PM -0400, Lee Revell wrote:
> On Mon, Mar 10, 2008 at 4:36 PM, Paul Davis <paul at linuxaudiosystems.com> wrote:
> >  On Mon, 2008-03-10 at 19:53 +0000, James Stone wrote:
> >  > 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.
> >
> 
> 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.
>

I don't think this is the problem. I asked (to the best of my
knowledge) about this on the xorg list and got this reply:

> "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."

Not at all.  We don't have a fifo like that, and I don't know any
xorg drivers for fifo-having hardware that have that bug either.
We may be keeping the PCI bus busy with our spinning on ring tail
reads when we're waiting for hardware idle or otherwise trying to
get ring space, but we do one of those and then a gettimeofday
for timeout handling anyway, so you shouldn't be all that busy I
don't think.

That FIFO issue is completely separate from any vertical sync
issue.  We do no syncing to vblank for plain 2d rendering anyway.

James