Unfortunately, your particular camera model may not work for this. USB devices must specify interface descriptors, and camera manufacturers often pick a terrible set of descriptor parameters that don't actually reflect the bandwidth saved by downsizing the image. If you run 'lsusb -v', you can search for the camera, and often find a number of things like:
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 4
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x1400 3x 1024 bytes
bInterval 1
If there isn't an appropriately-sized descriptor (one which is both large enough to handle your video stream, but small enough that 2 of them will not overload the bus), then the call to open fails. There are basically 3 things you can do about this:
- Get each camera on a separate USB bus (this may be as simple as moving which ports they are plugged into, but it may also be impossible on your current computer).
- Buy a different set of cameras, which have better choices for frame size.
- Hack the usb driver (very advanced and not recommended). The reality is that the USB bus bandwidth calculation is based on the overly-sized estimate from the device, and is already leaving some extra bandwidth, and so you could probably hack the driver to always go ahead with the opening the endpoint even though the check fails. Before I started using the Kinect, I did do a bit of looking around at this (there is a usb video driver forum which has a lot of information), but decided that replacing the cameras with different ones was the easier approach.
