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. >> 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. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
