Hello, On Monday 01 July 2013 13:19:05 Ming Lei wrote: > On Sun, Jun 30, 2013 at 11:02 PM, Alan Stern wrote: > > Clement and Laurent: > > > > The two of you seem to be the people who make the most use of > > isochronous USB transfers. Since the ehci-hcd driver is being changed > > to use a tasklet for URB completion callbacks, it looks like I will > > need to reconsider how isochronous underruns get handled. > > Without using tasklet, the hard interrupt handler still can be delayed > for some time, and switching to tasklet doesn't change the fact of the > probable delay of URB handling. > > > The basic prolem is simple enough: What should the HCD do when an > > URB is submitted after an isochronous pipeline has emptied out? > > I think some time-related data should be helpful for the discussion, for > example, how long the isochronous pipeline may become empty in current > audio/video driver(application) without any URB resubmit during the period? > > > The problem will be more acute than in the past, because URB > > resubmissions will no longer be synchronous with URB completions, > > thanks to the tasklet. That is, in the current code, if the completion > > handler resubmits the URB, the resubmission occurs before the HCD > > finishes the completion callback. But in the new code, the HCD will > > simply hand the URB over to the tasklet, and the resubmission won't > > occur until some time later (when the tasklet wakes up and invokes the > > completion handler). As far as the HCD is concerned, the completion > > The delay should be very small(generally several microseconds) since > isochronous URBs are completed in high priority tasklet. I don't think > the introduced tasklet delay is a problem for EHCI since per EHCI spec > the maximum rate at which the host controller will issue interrupts is one > microframe(125us), which means isochronous transfer completion can be > reported to CPU with about 125us delay in hardware level. > > > will already be finished. > > > > Thus, for example, even if the pipeline contains only a single URB, with > > the current code it will not become empty. But with the new code it will. > > If the load on the system is too high, the pipeline could empty out even > > if it normally contains two or more URBs. > > Single URB may not work well too when running complete() in hard > irq context. > > In UVC driver, looks it may submit at most 5 URBs which can include max > 32 packets, so it will take about 5*32*125us(20ms) to make isoc pipeline > empty suppose the interval is 1uF. That's correct. Unlike the UAC driver, the UVC driver doesn't care too much about exact timings. Avoiding packet loss is my main concern. As video frames are not delivered to userspace before they are fully transmitted, and given the large number of URBs required to transmit a video frame, I can submit more URBs (without reasonable limits) if that can help avoiding underruns. > But I don't know how USB audio driver uses URBs, and could it > submit only one isoc URB to playback/record audio data? > > > 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. > > IMO, we should try to avoid the situation, and in UVC cases looks it is > impossible to see an URB being submitted to an empty queue except > for at the moment of starting streaming or interrupt disabled for extremely > long. A couple of users have experienced underruns in the past due to a rogue driver disabling interrupts for tens of milliseconds. I don't think switching to tasklets will have a strong adverse effect, the 20ms buffer time should be large enough to avoid underruns in sane systems. > > 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. > > > > 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. > > > > Something in between... > > > > What would be best for your purposes? Or do you have any different > > suggestions? -- Regards, Laurent Pinchart -- 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
