On Friday 06 October 2006 9:38 pm, Christopher "Monty" Montgomery wrote:
> You say 'fell behind', I say 'xrun'... Did I come away with the wrong > interpretation? When you said that we had previously reached the conclusion that there was no bug there, I disagreed ... we hadn't discussed that point. When I looked into it this time, I noticed one non-audio bug; and you've pointed out that there's an interface issue/bug too. > > What would the upper layer do with that information though? Your > > patch just ignored it. So I don't see the point of reporting it... > > It ignored it only in that specific case; because it was in > snd_pcm_prepare, we knew no transfer we cared about was going on, and > as such, ignoring it was entirely correct. 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! > We *do* care about any > missed slots or xruns once the stream is flowing. We care very much. > > Right now, usbaudio is demonstrably deaf to any xruns so long as its > own buffers didn't empty. 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. :) 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.) > > One indication is clearly that urb->start_frame would hiccup. But > > I don't think the audio drivers track that... > > Alan mentioned that too I think. Is that a useful path for immediate > notification at submission, or would it only relay at completion? Completion only; drivers may not look at urbs they've submitted until they've completed. > The > problem with relaying at completion is adding unnecessary latency to > the report... "oh by the way, an underrun happened at some point a few > packets ago..." as opposed to "there is a gap happening right now" > (which is what EL2NSYNC gave us). Understood. > > If ALSA needs such an indication, your patch didn't add one ... ALSA > > would never have seen any XRUN indication in the first place. > > I didn't mean to suggest that the patchset was a completed work. > There's no rebalancer, I've not really inspected several annoying > usbaudio bugs, etc. 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? 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. > Of course, that depends on application; I'm talking about the low end > of the envelope. I'm normally running with about 32ms of measured > latency right now. XMMS could be a full second without caring... > > Or did I misunderstand the question? 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.) That rule of thumb applies to IRQ latencies... > > If it has to happen then, the notification has to be an error return > > such as EL2NSYNC, which will also indicate "didn't queue the URB". > > You would then need some kind of URB submission flag to override > > such reports so the schedule slot isn't abandoned, right? > > I like the EL2NSYNC approach, obviously. I thought there had been > objection to it and a desire to use something else (ie, that there is > already a preestablished convention). I think Alan was referring to the -EXDEV fault report thing, which a quick grep tells me is currently UHCI-specific. - Dave ------------------------------------------------------------------------- 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
