Alan Stern wrote: > [...] > This means that the HCD will have trouble telling the difference > between an underrun and a normal restart of a stopped I/O stream. In > both cases it will see an URB being submitted to an empty queue. > Here's where the URB_ISO_ASAP flag will be useful; if that flag is set > then the URB is restarting a stopped stream, but if it isn't set then > the pipeline experienced an underrun. > > Naturally, under normal circumstances this won't matter, because > underruns shouldn't occur. But I know from experience that people try > to push the latency as far down as they can, which increases the > likelihood of underruns. > > There are several possible things the HCD could do when an underrun > occurs: > > 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.
The word "might" shows an important point: due to software and hardware racing against each other, it is _not possible_ to know whether some URB to be submitted will actually still be on time or not. > 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. For audio, it is important to _try_ to transmit the packet at the _correct_ time; a guarantee that the packet will be transmitted at _some_ time would be worthless. (This is what "isochronous" is all about.) That the error reporting is delayed from submission to the completion callback is no problem. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
