On Sun, Jun 21, 2020 at 09:25:53PM -0500, Sid Spry wrote: > I now must ask the list: What is the relation of the isochronous endpoint setup > to the allocated bandwidth on the bus? Bandwidth allocation is determined by the host controller driver, or in the case of xHCI, hardware. Therefore it will vary with different drivers or controllers. > I understand the limit of 3 1024 byte > transfers per frame, but this says nothing about how it will be allocated or > how a device is refused bandwidth. Do I need to look for link degradation on > the application layer? It seems like having a single non-spec device means > the OS can't arbitrate link bandwidth. If allocation fails, the application will find out either when it tries to issue a Set-Interface request or when it tries to submit an isochronous URB. Did you say earlier that your host controller is xHCI? If it is then the OS doesn't arbitrate link bandwidth; the xHCI hardware does. > Also! > > For the list's consideration I have included an accepted but nonworking > configuration that perplexes me. The application note for the original device > I used specified a set of descriptors which was like so (device and > configuration omitted): [apparently irrelevant details omitted] > libusb seems to encounter an error: > > (pyusb error output) > ``` > >>> import usb > >>> ds = [d for d in usb.core.find(find_all=True, idVendor=0x1d6b, idProduct=0x0104)] > >>> d = ds[0] > >>> d.set_interface_altsetting(interface=1, alternate_setting=1) > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File "/usr/lib/python3.7/site-packages/usb/core.py", line 902, in set_interface_altsetting > self._ctx.managed_set_interface(self, interface, alternate_setting) > File "/usr/lib/python3.7/site-packages/usb/core.py", line 102, in wrapper > return f(self, *args, **kwargs) > File "/usr/lib/python3.7/site-packages/usb/core.py", line 204, in managed_set_interface > self.backend.set_interface_altsetting(self.handle, i.bInterfaceNumber, alt) > File "/usr/lib/python3.7/site-packages/usb/backend/libusb1.py", line 807, in set_interface_altsetting > altsetting)) > File "/usr/lib/python3.7/site-packages/usb/backend/libusb1.py", line 595, in _check > raise USBError(_strerror(ret), ret, _libusb_errno[ret]) > usb.core.USBError: [Errno None] Other error > ``` > > (libusb error from C code) > ``` > libusb: error [op_set_interface] setintf failed error -1 errno 32 > ``` Error 32 means that the device returned a STALL status when it received the Set-Interface request. The code responsible for this error response might be in FunctionFS or in your driver. > But, if interface 1 alternate setting 0 is dropped, and interface 1 alternate > setting 1 is kept, both invocations work and my C code spits out data very > fast, although I must inspect it further as I seem to be duplicating data in my > reads. If you drop altsetting 0 then you're probably not issuing a Set-Interface request. That would explain why you don't get a failure. If you like, you can try issuing a Set-Interface(0) request (even though it's redundant) just to see if it fails. Alan Stern
