On Sun, 30 Jun 2013, Clemens Ladisch wrote: > 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. That's a very important point. On the other hand, sometimes it _is_ possible to know that a particular slot has already expired (for example, if a register read indicates the hardware has already reached frame N+1 then we know that frame N is over). > > 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. Should the behavior change if the submission is _extremely_ late? The rogue driver leaving interrupts disabled for over 50 ms is a good example (and one that I actually encountered!). Even when that happens, would you prefer to require the audio driver to submit 50-ms worth of URBs before doing any real I/O? Alan Stern -- 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
