while using libusb, for Isochronous OUT transfers the callback function is not reporting actual length in windows 10

[chaitanya77185]

Hi, I was using libusb for reading and writing data to usb devices through isochronous endpoints. For isochronous In endpoint it is reporting actual length(transfer actual length & isochrnous packet actual length) received in the call back function. But for Isochronous OUT endpoint it is always 0. I have captured bus trace using lecroy, in that i can see data transferred.But the actual length is reported as zero(transfer actual length 7 isochronous packet actual length) in Windows 10. In windows 7 it is working as expected.The problem is only with windows 10. I am using usdk version v1.00-19.

Thanks in advance.

[ybendito]

@chaitanya77185 Thanks for reporting, we'll check it. Please specify what is your USB controller and whether your USB device is full speed or high speed (for example, saved info from usbview). Note that for Isoch OUT there are only two possibilities (for each frame/microframe): a) the packet was transferred completely (usually), or b) the controller missed the packet and did not transfer it at all. There are no acks on Isoch packets. You can temporary use this fact until the fix is available.

[chaitanya77185]

Hi @ybendito , Thanks for your response. It's 2.0 high speed device. But I observed this same issue with full speed devices also and only in windows 10. I captured the usb bus trace (using lecroy logic analyzer) and I can see that the data is being transferred. I captured host side trace also using microsoft message analyzer in that I can see length completed field is giving corrected value , I will attach screenshot of it.

Thanks & Regards, chaitanya.

[chaitanya77185]

Hi @ybendito , Is there any progress in this issue.

[ybendito]

Yes, for ISOCH OUT transactions the USBDK driver might be a little not consistent in what it returns in TransferResult. That's due to value that it receives from the USB subsystem. In general, because the 'Length' field for OUT transfers is not used, it may be set by the HUB driver as it wants. The important field is the TransferResult (status). If it is 0, the OUT packet was transferred. https://msdn.microsoft.com/en-us/windows/desktop/ff540414 I agree that it would be good to return more consistent result from the USBDK, we'll take care on that, but it will not contain more information.

[vijaykumarprathipati]

Hi @ybendito ,

I am facing the same issue. The USBDK driver returns proper length in Windows 7, but not on Windows 10. Previously you mentioned that

If it is 0, the OUT packet was transferred.

If the controller Missed the packet, will the transfer status still be 0 ? How can we distinguish the Transfer Complete vs Transfer Miss from the Application(libusb) point of view. This issue is somewhat making us to limit our Applications only for Windows 7.

Thanks in Advance, -Vijay.

[ybendito]

@vijay If the controller did not succeed to transfer OUT packet, the status of the packet will be erroneous. Status = 0 means the packet was transferred.

[vijaykumarprathipati]

@ybendito

Thanks for your Help. So How should we proceed with this issue further ? Bit Strange that it is working on Windows 7 but not Windows 10.

[ybendito]

The fix for this issue was merged into master branch, it will be in the next release. @vijay I do not believe this could be a reason to limit the usage. You receive exact per-packet status and easily can adjust the application to ignore these 'zero-length' in case the status is successfull. Actually, the controller does not provide exact length info for isoch out packets, only status.

[vijaykumarprathipati]

When will be the next release happens. We tried building it and the build happened without any issues. But it is throwing an error that "Driver Installation Failed" when we invoke -i option. Is there any way that you can provide a build artifacts ? It would help us very much. We are trying to verify that the fix solves our issue or not?

Please help us with these.

Thanks, Vijay.

[ybendito]

@vijaykumarprathipati If you want to use your own build: please verify you enabled signing of the driver and the machine is configured for test signing (bcdedit /set testsigning on).

[cl-ew]

@ybendito In your commit message:

According to interface definition, the UsbDk shall return actual length on transfer completion. For isoch OUT transfers the controller does not return it on respective URB field on Win10 and the updated WDK documentation states this field is not used for ISOCH OUT transfers. Current commit populates the initial packet length in the URB, making the result consistent on both Win7 and Win10.

Can you please provide a link to this WDK statement?

I couldn't find it on https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/wdfusb/nf-wdfusb-wdfusbtargetdevicecreateisochurb - perhaps it's documented somewhere else?

[ybendito]

@cl-ew https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/usb/ns-usb-_usbd_iso_packet_descriptor

[chaitanya77185]

Hi @ybendito , Can we distinguish the missed packets from other packets, So that we can check status of the packets which are not missed.

Actually I have observed something related to missing packets in libusb . In windows_usbdk.c , usbdk_do_iso_transfer calls usbdk_helper.WritePipe(priv->redirector_handle, &transfer_priv->request, overlapped); After this call I have observed "overlapped->Internal" is giving I/O pending status code(which may means packet is sent to the controller and being processed) when packets are not being missed. Based up on this , if libusb can distinguish between missing and actual packets which are sent(this may not be success). We can check the status (in callback function) of the actual packets and ignore missing packets or in windows_usbdk.c can update the length of the packets with initial lengths for successfully completed packets.

Please give your opinion on this.

[ybendito]

@chaitanya77185 Indeed, you may find some correlation between pending IO and successfully transferred packet, but this is not a strict relation. I think the best known result is the status of entire request, i.e. USB_DK_TRANSFER_REQUEST.Result