On Mon, 3 Sep 2012, Clemens Ladisch wrote: > Alan Stern wrote: > > On Mon, 3 Sep 2012, Clemens Ladisch wrote: > >> Alan Stern wrote: > >>> Alternatively, the host controller driver could fail the next 40 ms > >>> worth of isochronous URBs, so that the higher-level client catches up > >>> to where it should be. The failure could occur during submission, or > >>> the URBs could be accepted and then forced to complete immediately, > >>> with no data transferred. > >> > >> Both would be possible. At the moment, a submission failure would cause > >> the driver to stop the stream and report an error to the application. > > > > A submission failure is cleaner than an immediate completion, because > > we could then avoid making a whole series of doomed submissions (and > > using up a lot of stack space). On the other hand, it would be > > necessary to tell the client how many slots have to be skipped. > > The audio driver wouldn't care. Logically, it starts a new stream.
Really? Why not just skip a few packets and carry on with the existing stream? Does the behavior vary (or need to vary) according to the stream's direction? Logically, the situation isn't very different from what happens when packets are lost in transit (except for the fact that outgoing packets can be lost without the host's knowledge). Isochronous makes no guarantees about packet delivery, and never retries. > >> In this kind of situation (where it's known that multiple packets have > >> not been transferred), it would be somewhat preferrable to report the > >> error instead of ignoring it. > > > > That's a good idea. I can add a warning message to ehci-hcd. > > I meant report to the client as an error, instead of silently dropping > packets. In fact this missing data is already reported. The status member of the usb_iso_packet_descriptor structure returns -EXDEV if a packet was submitted too late for its scheduled time slot. (The error-codes.txt documentation file says "partially completed", which isn't a very good description.) My reason for bringing this up is because I want to improve the way ehci-hcd handles such things. Right now it doesn't do a very good job; when faced with delays longer than the built-in "slop" setting (currently 10 ms) it completely loses track of what's happening. It thinks the late submissions are actually far too early (it's dealing with a hardware schedule arranged as a ring buffer with length 512 or 1024 ms) and never gets back on track. I've got a patch ready for testing that improves this behavior, but it fixes only part of the problem. Resynchronization afterward remains an issue. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
