On Tue, 13 Oct 2009, Clemens Ladisch wrote: > Alan Stern wrote: > > 1. For the first submission to a new stream, if ISO_ASAP isn't set > > then we probably ought to pay attention to urb->start_frame, to > > allow precise synchronization between streams. But the HCDs > > don't do this, partly because it's hard for drivers to set > > start_frame to a meaningful value. > > Would it be possible to add an API to read the current frame number? > I.e., is there any HC that does not have a register for this? There already is such a thing: usb_get_current_frame_number(). The problem is that drivers can't easily use the result because they don't know the scheduling constraints. Also, there is no analogous function to get the current uframe number on high-speed buses. > > 2. For continuing submissions to an existing stream, the behavior > > should depend on whether ISO_ASAP is set. If it is then the > > URB should be scheduled for the next feasible slot, even if > > that means skipping some slots. This is what Sarah is trying > > to do (bearing in mind that for her, "feasible" means beyond > > the end of the scheduling threshold). > > Is there any possibility for drivers to find out about scheduling > constraints like this or like the maximum time that URBs can be > scheduled in the future? We don't have anything like this at present. It could be added. > (The USB audio driver currently allows overall buffer sizes of less than > one millisecond for high-speed devices with a sufficiently small packet > interval, i.e., in that case, all packets are scheduled only a few > microframes in advance.) Clearly that won't work on hardware having the bug Sarah described. > > 3. If ISO_ASAP isn't set then the URB should be scheduled for > > stream->next_uframe, even if that slot has already expired. > > This is what you're asking for. > > The documentation isn't too clear about the actual behaviour of > ISO_ASAP. It seems to imply that it is just a shortcut for drivers so > that they do not have to compute start_frame as last_frame+interval > themselves. In fact, the following explanation looks more like case 3 > than 2: > | For isochronous endpoints, your completion handlers should (re)submit > | URBs to the same endpoint with the ISO_ASAP flag, using multi-buffering, > | to get seamless ISO streaming. The documentation isn't good and the implementations aren't good. :-( Drivers never have to compute last_frame + interval, because the start_frame value is used as an input only in cases where the stream hasn't yet been started. What I described is the actual intention behind the current implementations, even if they don't always live up to it. Where the documentation deviates from my description, the documentation is wrong or out of date. Even the P in ISO_ASAP has to be taken with a grain of salt; a better way to put it would be "as soon as possible while still being usable" or "as soon as feasible". 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
