Daniel Mack wrote:
On 11/02/2011 04:49 PM, Clemens Ladisch wrote:
Example with queue length = 2:
- startup: driver queues both capture URBs
- 1st capture URB completes: driver queues 1st playback URB and requeues 1st capture URB
- 2nd capture URB completes: driver queues 2nd playback URB and requeues 2nd capture URB (all URBs are now queued)
- 1st capture URB completes: 1st playback URB is still busy (The playback URB might have been scheduled for a later frame, and even for the same frame, there is no guarantee that the completions for different endpoints happen in the same order as the queueing.)
I see. However, this really never happened in my tests so far.
This depends on how the HC drivers organize their internal data structures. (Most HCs have one global interrupt handler and check the endpoint queues in the order in which the endpoints are listed in the device's descriptors, or by number. However, xHCI allows multiple interrupts, so completion can arrive in random order, or even concurrently.)
What would be a way to fix this? Queue less capture urbs than available slots for playback urbs?
There is still that delay in the first playback URB (IIRC EHCI uses 10 ms), and there is no guaranteed upper bound on interrupt latencies.
Generally speaking, a playback URB can be submitted only when both itself and the corresponding capture URB have been completed.
In my misc/ua101.c driver, I store 'free' playback URBs and capture frame counts in FIFOs, and submit playback URBs from a tasklet that is triggered from both completion handlers.
Regards, Clemens