Hi Nathan, Increasing the frame increment reduces the number of errors somewhat, but the same errors still occur enough to fill the log file very very fast... I tried various values for the frame increment. The reduction in data loss between `frame += 4` and `frame += 1000` is about 5% (using 8 contexts and 16 packets per transfer, if that's relevant information). `frame += 1000` has the negative side effect of data acquisition coming in in big chunks instead of smoothly, for reasons I don't understand at all.
Anything else I should try? Many thanks! Ellis On Mon, Jun 25, 2012 at 10:52 PM, Nathan Hjelm <hje...@me.com> wrote: > If the transaction should be working the user could try to change how far in > the future the isoc transaction is scheduled for. He can do this by changing > line 1370 (in 1.0.9) from: > > frame += 4; > > to > > frame += 6; > > or something similar. > > -Nathan > > On Jun 24, 2012, at 08:28 PM, Xiaofan Chen <xiaof...@gmail.com> wrote: > > On Sun, Jun 24, 2012 at 8:27 PM, Ellis Whitehead > <ellis.whiteh...@gmail.com> wrote: >> I had hoped that I could make some progress by investigating this >> further myself, but wasn't able to figure much out... It seems to me >> in the log file that I posted, the log entry of most interest is this >> one: >> libusbx: debug [darwin_handle_callback] handling isoc completion >> with kernel status -536854513 >> That message is shown for most [darwin_handle_callback] entries, >> alternating sometimes with: >> libusbx: debug [darwin_handle_callback] handling isoc completion >> with kernel status 0 >> >> -536854513 presumably means kIOUSBNotSent2Err. Perhaps a helpful >> discussion about this error can be found in this thread: >> http://lists.apple.com/archives/usb/2007/Apr/msg00003.html >> But it's too technical for my current knowledge of mac and USB. In >> particular, maybe this comment is relevant? >> >> "if you take a look at AppleUSBOHCI.cpp, you'll find that >> kIOUSBNotSent2Err >> corresponds to OHCI status 15. You can look that up in the OHCI spec. A >> not >> sent error occurs because your request is never put onto the bus. This >> usually happens if the request is for a frame number in the past, or too >> far >> in the future. I think that all your requests are for a time in the past, >> so >> they never get put onto the bus by the controller." >> http://lists.apple.com/archives/usb/2007/Apr/msg00008.html >> >> Anyone have any suggestions? > > I am not an expert here so hopefully others can help you. Maybe > Nathan can help you here. > > Anyway just a wild guess here. What if you increase the > ISO_PACKETS_PER_TRANSFER from 8 to 16 or even higher (say 64), > does that help? > > #define ISO_CONTEXT_COUNT 8 > #define ISO_PACKETS_PER_TRANSFER 8 > #define ISO_PACKET_SIZE 600 > #define ISO_TRANSFER_SIZE (ISO_PACKETS_PER_TRANSFER * ISO_PACKET_SIZE) > >> Here is the output from lsusb -vvv for my device which isn't working >> on mac (but, as described previously, works fine on linux): >> >> Bus 002 Device 006: ID 088d:0006 >> Device Descriptor: >> bLength 18 >> bDescriptorType 1 >> bcdUSB 2.00 >> bDeviceClass 0 (Defined at Interface level) >> bDeviceSubClass 0 >> bDeviceProtocol 0 >> bMaxPacketSize0 64 >> idVendor 0x088d >> idProduct 0x0006 >> bcdDevice 0.02 >> iManufacturer 1 Syntech NL >> iProduct 2 IDAC 4 >> iSerial 0 >> bNumConfigurations 1 >> Configuration Descriptor: >> bLength 9 >> bDescriptorType 2 >> wTotalLength 39 >> bNumInterfaces 1 >> bConfigurationValue 1 >> iConfiguration 0 >> bmAttributes 0x80 >> (Bus Powered) >> MaxPower 32mA >> Interface Descriptor: >> bLength 9 >> bDescriptorType 4 >> bInterfaceNumber 0 >> bAlternateSetting 0 >> bNumEndpoints 3 >> bInterfaceClass 0 (Defined at Interface level) >> bInterfaceSubClass 0 >> bInterfaceProtocol 0 >> iInterface 0 >> Endpoint Descriptor: >> bLength 7 >> bDescriptorType 5 >> bEndpointAddress 0x01 EP 1 OUT >> bmAttributes 2 >> Transfer Type Bulk >> Synch Type None >> Usage Type Data >> wMaxPacketSize 0x0040 1x 64 bytes >> bInterval 0 >> Endpoint Descriptor: >> bLength 7 >> bDescriptorType 5 >> bEndpointAddress 0x82 EP 2 IN >> bmAttributes 1 >> Transfer Type Isochronous >> Synch Type None >> Usage Type Data >> wMaxPacketSize 0x0258 1x 600 bytes >> bInterval 1 >> Endpoint Descriptor: >> bLength 7 >> bDescriptorType 5 >> bEndpointAddress 0x06 EP 6 OUT >> bmAttributes 1 >> Transfer Type Isochronous >> Synch Type None >> Usage Type Data >> wMaxPacketSize 0x0005 1x 5 bytes >> bInterval 1 >> > > Technically this USB device violate the USB specification. > USB 2.0 specification Section 5.6.3. > "All device default interface settings must not include any isochronous > endpoints with non-zero data payload sizes (specified via wMaxPacketSize > in the endpoint descriptor). Alternate interface settings may specify > non-zero data payload sizes for isochronous endpoints. If the isochronous > endpoints have a large data payload size, it is recommended that additional > alternate configurations or interface settings be used to specify a range of > data payload sizes. This increases the chance that the device can be used > successfully in combination with other USB devices." > > On the other hand, the violation of the USB spec does not seem to > be the real problem here. > > -- > Xiaofan > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > libusbx-devel mailing list > libusbx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libusbx-devel > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
