[alsa-devel] Use of start_frame in usbusx2yaudio.c
clemens at ladisch.de
Wed May 12 14:51:52 CEST 2010
Sarah Sharp wrote:
> Are there any drivers in the kernel that set urb->start_frame on every
> Could those drivers handle it if only the first URB they submitted to
> the host controller was scheduled for that frame ID, and all the rest of
> the URBs were scheduled ASAP?
> I see there are three drivers that set start_frame (while not setting
> - drivers/isdn/hisax/st5481_d.c
> - drivers/usb/core/devio.c
> - sound/usb/usx2y/usbusx2yaudio.c
> I'm not really sure what usbusx2yaudio.c is doing. I think when one URB
> completes, it sets the next URB's start_frame to the previous URB's
> start_frame plus the number of URBs (2 by default) times the number of
> packets (4 by default). Isn't this basically like setting URB_ISO_ASAP?
For an audio driver, anything except ASAP (or the equivalent computation)
would not make sense because then there would be a gap in the audio
> What is usbusx2yaudio.c attempting to do? I've tried to get an overall
> picture of what it expects the isochronous scheduling to look like, but
> I'm finding the driver a bit hard to read.
AFAIK it just wants a continuous stream of packets, like the other
> I really can't tell what fall back method is if this submission fails.
So I guess xHCI does not support start_frame? A few other, seldom-used
HC drivers get away with silently ignoring start_frame:
ohci-hcd.c: /* yes, only URB_ISO_ASAP is supported, and
* urb->start_frame is never used as input.
ehci-sched.c: /* NOTE: assumes URB_ISO_ASAP, to limit complexity/bugs */
More information about the Alsa-devel