As you have read in the release note, the delay is due to channel suspend which the libraries are doing to avoid the data corruption. This happens on USB2 only (not on USB3.0). The data corruption can be because of the Bulk or Interrupt transfers. It is a preventive measure implemented so that you do not see any data corruption. However, if it is crucial for you to avoid this delay over USB 2, please create a technical support case, we can modify the libraries to remove this channel suspend feature.
Thanks Nishant for your reply and the offer! Some more questions before we can decide on how to handle this:
Is the data corruption no issue on Isochronous IN Endpoints? Version 1.3.3 of the library also suspends isochronous endpoints.
Which data is potentially corrupted? The Endpoint 0 data or the data on the Bulk/Interrupt endpoints? Or both?
Looking at the source code of the library, it looks like the library is setting the suspend flag to each endpoint and than waits for up to 10 ms for the endpoints being suspended. So the 10 ms delay per endpoint we observe look like that the endpoint was not reporting being suspended yet, but the library rather time-outs after 10 ms waiting for the suspend to succeed. It this intended that way?
Thanks for your help!