David Brownell wrote: > On Saturday 07 October 2006 12:47 pm, Alan Stern wrote: > > We could in fact return an error code and _not_ accept the submission, > > counting on the driver to realize what went wrong and make a new > > submission. I think this is overly complicated. And it provides no hint > > as to exactly how many slots were missed. Finally, it increases the > > amount of work performed by both the higher-level driver and ehci-hcd -- > > exactly the sort of thing you _don't_ want to do when a stream is lagging > > behind. > > I don't know how ALSA works just now, but I suspect that it'd be better > to return a status code meaning "I couldn't queue this, your driver is > N uframes behind" so that the driver could retry intelligently by just > skipping those uframes. > > So this question is best answered by the drivers who would be using > that recovery mechanism ... notably ALSA and V4L2.
At the moment, the ALSA driver just queues its URBs and doesn't bother to check for completion errors (for playback). Any errors from usb_submit_urb(), however, are fatal. Reporting the queueing error through the completion handler would be easier for the driver (as shown by the patch that started this thread). Regards, Clemens ------------------------------------------------------------------------- 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
