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

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

zheng rong wrote:
> On the device side, the image frame size = 360960=512*705, so in the
> firmware the device will send 705 packets ended with a zero-length
> packet (totally 706 pkts). The camera streams images frame at about 30fps.

That's 10.8 MB/s.


> But when running 2 cameras in the same computer from another terminal
> (using the same executable binary file, but will request different
> camera serial number), these two cameras will lost data. Some transfers
> are completed, but the actual transfer length is less than the expected
> length(e.g. 360852 < 360960). It seems that the 2nd camera interfere the
> data transfer, which results in the incomplete data frame of 2 cameras.

Right.  This is EXACTLY why isochronous pipes were invented, and 
streaming video sources are the canonical example of the need for 
isochronous.  Bulk pipes all compete for the leftover bandwidth, after 
the scheduled and reserved services have been satisfied.  The host 
controller and its drivers make no guarantees about how they assign 
transfers in the frame schedule.

You have to understand how USB is implemented.  When the schedule says 
camera 1 can send, the host controller will send a "GO" signal telling 
it to send.  If it doesn't have anything right now, it responds with a 
NAK, and the host controller will keep retrying that read until it gets 
something.  Those retries are going to use up the bandwidth that you 
want to use for camera 2.

If you need guaranteed, real-time, scheduled bandwidth, then you should 
be using isochronous pipes, not bulk pipes.  It's just that easy.


> But in the result I got the same problem.

Right.  It's not a usage problem, it's an architecture problem.


> Another try is that, I defined the camera device class and declare 2
> camera objects. For each camera, I start a new thread to configure,
> submit transfer and run libusb_handle_events. But got the same problem.

Right.  It's not a usage problem, it's an architecture problem.


> 1. What may be the reason of this problem?

You have chosen the wrong endpoint type.


>    a. Bandwidth? I don't think so. I tested off-the-shelf USB2.0 camera
> on the same PC, 2 cameras can works fluently at 60fps for each. (the
> camera interface is USB2.0, and PC interface is USB3.0).

You're not comparing apples to apples here.  That USB camera was using a 
different frame format (MJPG, for example, would have frames even 
smaller than your 10MB frames), and that USB camera was almost certainly 
using isochronous pipes.  Plus, your problem is with TWO cameras sharing 
the bus.  Did you try TWO off-the-shelf USB cameras simultaneously?

There is roughly 45-50MB/s of usable bandwidth on a typical USB 2.0 
bus.  A single bulk device can sustain that rate over a bulk pipe, but 
bulk pipes were simply not designed to share fairly.  That's why they 
are called "bulk" -- they were designed for bulk data transfers that do 
not have real-time requirements.  When a pipe needs real-time activity, 
it needs to use a scheduled service -- isochronous.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.