Isochronous transfer improvement

[mcuee]

One of the main improvement of libusbk.sys vs libusb0.sys is that it has better isoc transfer support.

libusb0.sys may only work with full speed isoc transfer and not really with high speed or super speed isoc transfer.

I am not so sure if it is worth the time to enhance the isoc support now that libusbk.sys and winusb both support isoc transfer.

[dontech]

I am planning on using this driver for a long time, so if there is something broken in ISO support, the please report it.

Is it all HIGH speed ISO transfers that do not work?

[mcuee]

I am planning on using this driver for a long time, so if there is something broken in ISO support, the please report it.

Is it all HIGH speed ISO transfers that do not work?

Great that you are intending to support libusb0.sys for long term.

I will dig out the information and carry out some tests with Cypress FX3 development board and report here.

[mcuee]

Some info here from libusbk website. http://libusbk.sourceforge.net/UsbK3/usbk_comparisons.html

1) libusbK.sys advantages when compared to libusb0.sys:

Winusb-like power management. Winusb-like pipe policies. Driver-level asynchronous transfer timeouts. Improved isochronous transfer support. Newer, more robust KMDF based design.

2) libusbK.sys disadvantages when compared to libusb0.sys:

Does not support multiple configurations. Does not support a "filter driver" mode. Significantly larger device driver installation packages. Less tolerant of usb devices which or not fully compliant with usb specifications.

[mcuee]

One old proposal of improvement:

• https://github.com/mcuee/libusb-win32/issues/2

[mcuee]

From Travis about the libusb0.sys isoc support limitation: https://sourceforge.net/p/libusb-win32/mailman/message/28457157/

Using these basic transfer functions, libusbK.sys should be packing the valid bytes to the front of the transfer buffer. i.e. When the reap function returns the length, indexes 0 thru transferLength-1 contain your valid data. As you have noted, this is not necessarily true for libusb0.sys. Instead the data remains indexed in packet frames and you have no way of knowing which parts of the transfer buffer are valid.

libusb-win32 does transfer splitting in the dll (libusb0.dll). This does not really work for ISO pipes on transfers larger than 64k (hard coded) because it waits for each batch to complete before submitting the next. i.e. There must always be multiple pending transfer requests.

[mcuee]

Travis mentioned that libusb0,sys may work with high speed isoc transfer in many cases but sometimes it will not work. https://sourceforge.net/p/libusb-win32/mailman/message/26366939/

---

On Mon, Oct 4, 2010 at 9:13 AM, Graeme Gillgraeme2@... wrote:

One thing I noticed when adding libusb0.sys to libusb v1.0, is that the isochronous support is not quite the same. libusb v1.0 supports a packet size for each packet, whereas libusb0.sys assumes a constant packet size for a given transaction. Perhaps this is something that could be added to libusb0.sys ?

Yes, it could. And I agree that this is something we should look at adding. I remember reading something about this in your 1.0-back-end code comments. ;)

One problem here is that a 'libusb_iso_packet_descriptor' is a bit different than what windows will use. http://libusb.sourceforge.net/api-1.0/structlibusb__iso__packet__descriptor.html http://msdn.microsoft.com/en-us/library/ff539084%28VS.85%29.aspx However, we would still need to allocate USBD_ISO_PACKET_DESCRIPTOR structures in the driver. IE: The user mode iso packet descriptors would not necessarily have to be USBD_ISO_PACKET_DESCRIPTOR.

There is room for improvement in libusb-win32 where iso transers are concerned. It also does not really support high speed ISO endpoints, although it will still work in many cases.

(For backwards compatibility the best approach would be to add a new IOCT.)

Yes, To do this correctly it would need to be a new IOCTL. The problem here is the iso packet descriptors need to be updated and passed back to the user. If it wasn't for this we could probably squeeze it under the same IOCTL.

I tend to think this is not so easy.

It would take some work. Support for all of this would have to be added to the dll as well.

On the other hand, I do not have a good understanding of the libusb-win32 isochronous transfer functions myself even though I tried it before and it seems to work fine.

libusb-win32 doesn't support all iso transfer scenarios. In-fact it really only supports a scenario where the the device is full speed and iso packet size is constant for all packets.

Regards, Travis

[mcuee]

BTW, libusb0.sys works very well for super speed bulk transfer, beating WinUSB and libusbk.sys in terms of performance based on my testing and Travis' testing using Cypress FX3 development board when working on libusbk 3.0.8.0/3.1.0.0 release earlier this year.

[mcuee]

Reference testing results: Cypress FX2LP HighSpeed USB cystream example. https://github.com/mcuee/libusbk/issues/57