On Wed, 2002-02-06 at 12:04, David Brownell wrote: > > 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. > > 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. 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. 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. Thanks, --gmcnutt _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
