Re: [PATCH 1/5] ALSA: snd-usb: implement new endpoint streaming model

[Clemens Ladisch <clemens@ladisch.de>]

Daniel Mack wrote:
> On 11/02/2011 04:49 PM, Clemens Ladisch wrote:
> > Example with queue length = 2:
> >
> > 1) startup:
> >     driver queues both capture URBs
> > 2) 1st capture URB completes:
> >     driver queues 1st playback URB and requeues 1st capture URB
> > 3) 2nd capture URB completes:
> >     driver queues 2nd playback URB and requeues 2nd capture URB
> >     (all URBs are now queued)
> > 4) 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