Sarah Sharp wrote:
> Are there any drivers in the kernel that set urb->start_frame on every
> URB?
>
> 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
> URB_ISO_ASAP):
> - 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
output.
> 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
audio drivers.
> 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 */
Regards,
Clemens
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
