On Tue, 28 May 2013, qse drf wrote: > > It's still hard for me to figure out understand how this could happen. > > If you don't SEND the second buffer until you have RECEIVED the first > > result, how could you even get the first result unless the first buffer > > was already gone? > > That's the problem. The supposedly synchronous function calls each return > success > as I call them in order: OUT 1KB, IN 16B, OUT 1KB, IN 16B > But the bus trace shows: OUT 2KB, IN 16B, IN 16B > This is the case even if I add a 5 second delay after each call to > libusb_bulk_transfer.
I have to admit, this piques my curiosity. Did the bus trace show that the second KB in the 2-KB OUT contained the data that your program was _going_ to submit for its second OUT transfer? Or was the data on the bus nothing but zeroes and garbage? For that matter, what happens if you change your program so that it doesn't submit the second OUT transfer at all? Do you still see a 2-KB OUT transfer on the bus? Is it possible that what really happens is that Windows buffers data from an earlier IN transfer? It could send that buffered data to your program as soon as the first KB has been sent out. Then it would require two more IN transfers on the bus: one for the programs second IN request and one to buffer for later. This would explain what you observe. Alan Stern ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
