Re: How should we handle isochronous underruns?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 20 Jul 2013, Ming Lei wrote:

> > No, we don't have to change every driver using isochronous URBs.  Many
> > of them set URB_ISO_ASAP on every URB -- in fact, AFAIK snd-usb-audio
> > is the only one that has been fixed not to do this.
> 
> OK, if you are sure just snd-usb-audio and very less drivers need the change,
> using the API only is correct way.

I haven't checked in detail, but this seems very likely.

> >> > But never mind.  For a new API, how about
> >> >
> >> > void usb_new_iso_stream(struct usb_device *, struct usb_host_endpoint *);
> >> >
> >> > Does that look okay?
> >>
> >> Looks you missed one parameter of 'int on'.
> >
> > I don't understand.  Why is another parameter needed?
> 
> So do you only want to set streaming on and not streaming off?
> If so, that looks a bit weird, could you describe its usage?

The new call doesn't turn streaming on or off.  The driver does that 
by submitting URBs or not submitting them.

The new call merely separates an old stream from a new one.  It tells 
the HCD that the old stream (if any) is finished, so that any URBs 
submitted in the future will belong to a new stream.  In particular, it 
tells the HCD that the next URB for this endpoint should be assigned to 
a time slot that will be visible to the hardware, instead of being 
assigned to the next time slot after the last packet of the previous 
URB (which has probably expired already).

In short, it would simply tell the HCD to act as though the next URB
has URB_ISO_ASAP set.  For HCDs that act as though URB_ISO_ASAP was
always set, the new call wouldn't do anything -- they would not need to
implement it.

> > (with extra overhead for every URB!) to fix a problem that ought to be
> 
> In a normal system, the URB count won't be very much(<< 1000), and if
> you mean the overhead is from memory, I guess it won't cause real memory
> increase per URB for slab's sake. If you mean performance loss with
> set/get the single lockless/common variable, maybe we should focus on
> the big HCD lock, which might be the biggest bottle of USB protocol, :-)

If you're talking about the hcd_urb_list_lock, note that it could
easily be made hcd-specific.  I haven't done that because the regions 
it protects are all very short, so there probably isn't very much 
contention.

> > fixed by changing drivers.
> 
> If only very less drivers need the change, I agree with you.

Okay, good.

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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux