NOTE: I updated $SUBJECT to be accurate. On Friday 06 October 2006 7:56 pm, Christopher "Monty" Montgomery wrote: > On 10/6/06, David Brownell <[EMAIL PROTECTED]> wrote: > > > > Hmm, in the current EHCI scheduler, the place which returns EL2NSYNC is > > arguably just a bug that should get fixed ... it even includes the > > comment "someday, try to reschedule". > > I'll point out we did discuss this and came to a different conclusion > a few months ago :-) But it's more important to be correct than > consistent...
A quick search of email that I exchanged with you on this topic only includes the following, from 4-June-2006: >>> The EL2NSYNC will happen on occasion, e.g. "fell behind" by having the >>> stream's transfer queue get empty in such a way (long irq latency, >>> insufficient iso urbs queued, etc) that some of the slots didn't have >>> a transfer ready (in the iso schedule). Not that I entirely trust that >>> modulo arithmetic there, but I've seen those failures when testing. That doesn't come across to me as a "different conclusion" at all... > > The problem scenario was, ISTR, that sometimes there would be iso URB(s) > > still in that stream's queue so that the recorded start point for the > > next URB (that is, scheduler state) was invalid. Why were they still in > > the queue? From what I remember, it was quite likely that the transfers > > in that URB were completed by the controller, but the IRQ handler had not > > yet cleaned them up ... either it had not yet been called, or more often > > it was currently _doing_ that cleanup, and this URB was being submitted > > from the completion handler of a previous URB. > > > > That is, in at least some of the common cases I had observed, the issue > > could have been resolved by using a more precise test: "are there ITDs > > that are still active?" (looking for ITD_ACTIVE/SITD_ACTIVE) rather than > > the quicker-but-sometimes-wrong "are there ITDs that haven't completed". (The actual sometimes-wrong test being effectively "are there ITDs"; it'd be simple enough to actually look at them all.) > > > > So I guess I'm strongly inclined to NAK patch 15/15 ... although maybe > > something in one of the earlier patches changed the El2NSYNC behavior. > > OK, so I don't have precedent to fall back on in my argument. > Nevertheless, there must be a way to notify the upper layers of a > schedule xrun. This is a clear means of doing so. 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... One indication is clearly that urb->start_frame would hiccup. But I don't think the audio drivers track that... > When my recording has gaps, but ALSA claims buffer fill never fell > below 90%, I am filled with a developer's most righteous rage. (It > happens, I'll send you some of the recordings if you care. ALSA never > threw xrun, and it's potentially clear in retrospect why-- there was > no way for USB to tell it slots got missed, so ALSA didn't know-- it's > buffers were still full!). If ALSA needs such an indication, your patch didn't add one ... ALSA would never have seen any XRUN indication in the first place. 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. > In any case, setting a status flag on the next completion is not good > enough; that tells you an xrun happend a long time ago. Notification > has to happen upon next submission. 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? Unless that return is given magic status inside usbcore, so that it's the first (and only!) return code that doesn't actually indicate an error ... - 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
