Duncan Haldane wrote:
>If two cameras are registered, one on /dev/video0 and one on /dev/video1,
>and I use e.g. xawtv or gqcam to monitor them, I cannot open /dev/video1
>when /dev/video0 is open and vice-versa. This happens for two cpia
>devices and one cpia + one ov511 device.
>
>If I try to start the ov511 device with the cpia one already running,
>it tries to open, but fails, and the running cpia device also hangs
shortly
>afterwards.
>
>
That's because both cameras are trying to use nearly all of the USB's
bandwidth. Or, more precisely, each is trying to schedule an ISO packet
of nearly the maximum size (1023, IIRC) at the same time. Only one will
get through. I'm not sure why that hangs the devices though; you'd think
it would just corrupt both cameras' images.
>Am I running into an intrinsic limitation of v4l1, or does this
>means something is screwed up
>in the cpia driver's v4; initialization, or whatever. Unfortunately,
>I dont have two ov511's to see if that combination works ok with v4l1,
>assuming that driver is correct.
>
>
It works, as long as you load ov511 with "cams=2". That will lower the
ISO packet size of each camera to 513 (which is still too big but seems
to work anyway, go figure). I've been able to get three OV511 cameras
working at the same time with packet size of 257, without problems
(other than a really crappy frame rate).
>Any suggestions? Should I expect to be able to simultaneously
>view two webcams with v4l1 if some cpia driver bug can be fixed?
>
Check the descriptors. As long as there's an alternate setting where
MxPS <= 1023 / 2 then you should be in business. You can either have the
packet size or alternate number be a module param, or you can do a
"cams" thing like ov511. Or, you can allow the frame rate to be set
somewhere, and have the driver automatically choose the minimum possible
packet size that can still sustain that frame rate.
The best methodology depends on the hardware design. Some hardware (eg.:
OV511) has no concept of a frame rate, for instance. Other hardware may
require the frame rate to be explicitly lowered when MxPS is reduced.
--
Mark McClelland
mark@xxxxxxxxxxxxxxxx
