Hello, Actually I am encountering the same problem. Any suggestions will be appreciated. Philipp > Hello, > > I've been unable to get two USB CPIA cameras to work reliably on the > same machine at more or less the same time. Either camera (/dev/video0 > or /dev/video1) will work fine by itself when the other camera is not > being used--the problem arises when trying to use them at or near the > same time. While it is possible to open /dev/video0 and /dev/video1 > simultaneously, if one device is in the middle of a VIDIOCMCAPTURE then > opening the other device fails with a "device or resource busy error". > If I coordinate the device openings to work around this problem (that > is, not starting captures until both devices are successfully opened), > then things fail if one card tries to do a VIDIOCMCAPTURE while the > other is already doing a capture. I haven't found any V4L api docs > anywhere that indicate that doing two captures at once on separate > devices from separate processes is not permitted. > > I have experimented with protecting the actual capture with a shared > memory semaphore so two processes never try to do a capture at the same > time. This seems to work mostly, though there are enough lingering > problems that I suspect that this may not be a proper solution. Does > anyone have a recommended approach? Has anyone else gotten two USB cams > working on the same machine reliably? If so, under what kernel/v4l > driver version? > > I am on kernel 2.4.0. The cameras are generic USB CPIA cameras made by > Ezonics. I have used a variety of test programs to explore the error > behavior, but my main test environment is two "motion" processes (, each > process controlling a camera. I have seen the same behavior with two > concurrent gqcam processes as well, but it usually takes longer to > manifest the problem with gqcam since gqcam spends a lot of time waiting > between successive VIDIOCMCAPTURE calls and therefore the probability of > both processes trying to do a VIDIOCMCAPTURE at the same time is lower. > Eventually, however, an error will occur. > > Any suggestions will be appreciated. > > Rich
