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? > 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? (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.) > 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. > IMO it wouldn't hurt to fix up all three HCDs to behave consistently > (but then what about all the other controller drivers?). _All_ HCDs should behave consistenly, of course. :) Best 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
