Martin Ling

There is plenty of code out there which assumes that multiple transfers submitted _on the same endpoint_ will be completed in order. Two examples that I'm familiar with which do...

Hi @sonatique, Something you may not be aware of is that there is an event handling lock, which can only be held by one thread at a time. When you...

@sonatique I think that in the scenario you describe, the queue ordering is still guaranteed. Your event handler thread and the various threads making sync calls cannot all hold the...

I remember running into this when I was working on sigrok, and I expect it's also the reason that HackRF can't stream at full sample rate on Windows. For both...

> Exactly. But there are some complexities as mentioned by Chris in #149 if we want to have a generic libusb_set_option approach to enable RAW_IO policy for bulk transfer and...

I don't think RAW_IO can be safely applied to selected transfers - I've gone into detail on this [here](https://github.com/libusb/libusb/pull/1069#pullrequestreview-937231429).

The shortcoming I see with the `libusb_set_option` approach is that it forces the setting to be applied at the context level rather than on an individual endpoint. I can imagine...

> That is not necessary. I think we can use `libusb_set_option(ctx, LIBUSB_OPTION_WINUSB_RAWIO, ep)` or even `libusb_set_option(ctx, LIBUSB_OPTION_WINUSB_RAWIO, intf, altf, ep)`. Oh, I'd missed that `libusb_set_option` is variadic. In that case...

> One point that speaks in favor of global context option is that sigrok, a library that interfaces with a lot of different USB devices, has been running with libusb...

Hi @zyp, I have just run into this issue from the IN side whilst working on the USB analyzer gateware. When capture has been stopped, we want to send out...