Pratyush Anand wrote: > On 6/30/2013 8:32 PM, Alan Stern wrote: >> It could schedule the URB for the first time slot known to be >> available, even if that means skipping some time slots which >> the hardware might (or might not) be able to use. > > IMO, this approach is better. To quote the USB spec: | Isochronous Data | A stream of data whose timing is implied by its delivery rate. Isochronous transfers are usually used for real-time applications where it is better to drop a single packet than to delay *all* following packets. >> It could try to schedule the URB for the next time slot after >> the last one used by the preceding URB, even if that time slot >> has already expired. > > There is no meaning of submitting an URB for expired time slot. Of course there is. The HCD cannot exactly know whether the current slot will expire before the URB is enqueued, so it is not always possible to label the slot as "expired" or not during submission. The meaning of an isochronous URB submission is "try to transmit this data in that frame"; whether the URB actually was transferred will be reported to the completion callback. 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
