> > > Ok, it *can* be automatically resubmitted, but how? > > > > Usually through linking urb->next fields in a ring. > > Ah. So I submit a ring, using the ASAP flag for all of them. Their > frames point into, say, a ring buffer kept by the driver. Hm... and then > the user process which reads/writes to the head of the ring buffer just > continously races the urbs? Seems precarious.
I think that if someone were to take a careful look at how ISO is done, and compare that to how it's supposed to be done (per the USB spec), some issues would turn up. And that's beyond the "Linux isn't real-time" class of issues that can prevent Linux from consuming (or producing) ISO data at the rates specified in devices' descriptors. > > Except that if you look at the mechanism for specifying a start frame, > > it seems a bit insufficient. Frame counters roll over, but drivers don't > > know their range.And there's a limit to how far in the future transfers > > can be scheduled, which is not visible to drivers. > > > > ASAP is the only behavior that's really workable with today's API. > > You mean the rollover point for a frame counter can vary from host to > host? I assumed the frame counter was always 11 bits. For OHCI it's 16 bits. For EHCI, the range is variable (8-10 bits). I'd suspect UHCI of being 10 bits. > How are ISO transfers supposed to be coordinated? I think I'm really > misunderstaning the model. I assumed that the Class Specs would indicate > some way for the host and device to agree on when they would start and > stop a "job". But maybe the concept of a "job" is totally unapplicable > to ISO. Could be -- what do you mean by a "job"? The ISO service model prioritizes "on time" delivery over the "error-free" type of all other transfer types. An ISO transfer request is basically a claim on bus bandwidth. > Maybe ISO is more like a wire that carries a signal. Once the > host sets a configuration which contains ISO endpoints, these wires are > all "hot" and "signal jitter" is up to the functions on either end to > deal with in their own way. I suspect that's closer to the right model. Look at the "sync frame" control request (9.4.11 in USB 2.0 spec). Somewhere I've seen some extensive adaptive models for how ISO synch is supposed to be maintained. Though note that for Linux-USB, the reservation comes when an URB is submitted, not when the configuration is set. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
