> 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.
All right. I guess I'll have to take a closer look at some existing host drivers to see how it is done. And maybe I should buy something and watch it with my CATC... anyone have any recommendations for a nice, cheap device with a complicated ISO usage model? > For OHCI it's 16 bits. For EHCI, the range is variable (8-10 bits). > I'd suspect UHCI of being 10 bits. For the record, my UHCI host rolls over at 2048 (or at least it does on the CATC trace -- I guess I'm assuming CATC doesn't mask off higher 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. > For "job" I was originally thinking of something like streaming an MPEG file. It has a beginning and an end, and if you miss an MPEG frame here or there it's no big deal -- as long as it plays at a consistent rate. But I suspect now that ISO works best for continous streams with no clear beginning or end (like an audio or video feed). > > 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. > Really? That surprises me because in 5.6.3 of the USB 1.1 Spec it states: "An endpoint in a given configuration for an isochronous pipe specifies the maximum size data payload that it can transmit or receive. The USB System Software uses this information during configuration to ensure that there is sufficient bus time to accommodate this maximum data payload in each frame. If there is sufficient bus time to accomodate the maximum data payload, the configuration is established; if not, the configuration is not established". Come to think of it, even if Linux-USB conformed to this, class drivers could work around it by using SET_CONFIGURATION behind the subsystem's back. Thanks for your replies, --gmcnutt _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
