On 10/7/06, David Brownell <[EMAIL PROTECTED]> wrote:
> No, not entirely correct; though I don't think anyone had previously
> pointed out that resubmitting wouldn't necessarily make the underlying
> issue go away!
Clemens asked about a week and a half ago. You weren't on the
explicit Cc: list though, I think, and the list still appears to be
bouncing more than half my mail (times out without being sent after
several days).
> I don't quite see how we (usb audio) _could_ care without getting
> fault indications ... and the lack of such indications is, at least
> historically, why usb audio is deaf. :)
Well, yes, but it's doesn't change the deafness :-)
(The white hot fury of the initial argument has passed and for some
reason, that last paragraph has me giggling and I can't stop)
> Right now you're probably giving ISO a much more careful look than
> anyone has yet done on Linux. Though mostly in the context of EHCI;
> I think if you look at OHCI you'll notice that it doesn't test for
> this EL2SYNC class of xrun, and thus won't report them. (And from
> what Alan said, I expect that's true of UHCI too.)
I used to use an old Powerbook (400MHz Titanium) for recording, and it
had two OHCI controllers. In three years of using the machine, I did
get one recording with an unexplained fault that the software did not
report (a gap in the stream from one of the eMagics), so I'm inclined
to agree. I've not looked at the source in detail, just enough to get
a feel of how the OHCI controller differed from EHCI.
Failures have been more numerous with EHCI (I've not had a event-free
show with it yet).
> OK. It'd help clarify things if you don't submit usbaudio patches
> as part of an EHCI patchset ... though I can certainly understand
> how fixing substantial issues tends to involve fingers going into
> other parts of the system! (Right now I'm chasing some "memory"
> controller timing issues. Darn I wish I had relevant docs on the
> I/O chip hooked up to the controller; trial-and-error is no fun!)
>
>
> > > How deep was the I/O queue that ALSA feeds? My rule of thumb for max
> > > IRQ latency of N msec has always been to queue 2*N msec of URBs.
> >
> > What do I have or what do I want? I *want* 2-5ms from sample to
> > playback. MacOSX can do it. Windows can do it. We can't, at least
> > not yet.
>
> We can't ... why? Because IRQ latency is too high, or something else?
I don't know; it just doesn't work properly. Below about 30ms of
buffer, underruns happen constantly and it's not the app software.
The machine is supposedly mostly idle. ALSA is unaware that underruns
are happening. This is true of both playback and sample.
Even with very deep buffers I still get occasional xruns, and I don't
know why-- but it is much less likely. Trying to trigger xruns didn't
seem to get anywhere; the machine seems bulletproof to load and
suddenly, wham, it will just lose a bunch of frames (or get an
unrecoverable EPIPE, or have all USB stuck in device wait, or lock
up... although it's been more than a year since a lockup).
> You may not have had reason to look at the PREEMPT_RT patchset much,
> but be aware that it's on the way, and one goal of it is to help with
> such issues.
That's good, I expect I'll want to test it out.
> When you say "measured latency" do you mean that you've seen IRQ
> latencies going up to 32ms? (That seems huge!!) Or instead that
> you're working with an audio pipeline that deep? (I'd hope that's
> sufficient.)
An audio pipeline that deep.
> That rule of thumb applies to IRQ latencies...
OK, I misunderstood. In fact I still don't quite understand ('IRQ
latencies' has meaning in that I know what they are, but they
obviously mean something very specific in the context of the Linux
kernel, and I don't know what that is).
> I think Alan was referring to the -EXDEV fault report thing, which
> a quick grep tells me is currently UHCI-specific.
Ah, so the good news is there's no precedent and the bad news is
there's no precedent.
Monty
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
