Re: [libusb] less data length in async bulk transfer with 2 cameras

[Tim R. <ti...@pr...>]

On Nov 1, 2018, at 9:06 PM, zheng rong <zhe...@gm...> wrote:
> 
>  
> > How did you fix the problem finally?
> 
> Third -- the real solution -- was to spin the camera board to add a 32k 
> external FIFO chip.
> 
> Would you please provide the part name of the external FIFO chip? 

I'll see if I can find that out.  It was 10 years ago...


> By far, I haven't get the isoc transfer work, even for one camera.
> 
> The bulk transfer looks very tidy.
> ...
> But the data length of the isoc transfer is messy even for one camera, which makes me confused.

That's the way isochronous works.  You need to read about this in the USB spec, because isochronous buffering is quite different from bulk and interrupt..  With bulk and interrupt pipes, things work in units of transfers.  You ask for 360,960 bytes, and the packets transfer until that packets fills.  But with isochronous, everything happens one packet at a time.  There is no concept of larger "transfers".  You'll provide a buffer that is some multiple of 8x3072 bytes, divided into individual 3072 byte packets.  That's why you have to prepare packet descriptors.

The result you get back is not one contiguous buffer.  You have to look at the packet descriptors to determine how much valid data is in each packet.  If you got all three transfers in a microframe, there will be 3072 bytes in that packet.  If you only got one transfer in a microframe, there will be 1024 bytes of data and 2048 bytes of garbage.  If you missed a whole microframe, there will 0 bytes of data in that packet.  You have to reassemble the frame from those packets.


> The result is confusing. 

It is if you are expecting an isochronous transfer to work like a bulk transfer.  It does not.
— 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.