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:

• Feature request: isochronous buffer packets offset/length #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 Gill<graeme2@...> 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.
mcuee/libusbk#57