Hi Denis, On Tuesday 04 May 2010 17:37:13 Dennis Muhlestein wrote: > On 04/29/2010 12:40 PM, Dennis Muhlestein wrote: > > One idea I've been toying with is to add a semaphore around submitting > > the URBs. > > > > In uvc_video.c, where the URBs are submitted, I'd acquire a semephore > > for each device currently submitting URBs. The semaphore would limit the > > number of devices to whatever number I decide can safely submit URBs > > simultaneously on the bus without throwing out of space errors. > > > > I did an initial test of this and it looks promising. I can configure > > all the cameras. As long as I don't submit the URBs for the number of > > devices beyond that which will work at the same time, the other cameras > > simply drop the data. > > > > I'm not sure the best places to control the locking and unlocking of the > > semaphore are. Right now, I lock it before submitting URBs in > > uvc_init_video. In uvc_video_complete, I unlock it and relock it if the > > buffer is complete (allowing another camera to acquire it and capture a > > frame). > > > > Anyway, it isn't working perfectly yet but I think I can debug it and at > > least get to a point where I know if it's worth pursuing. I'm curious if > > anyone can provide thoughts or alternatives. > > I have two solutions that I've come up with this so far. > 1) Modify the uvc_video.c to queue urbs in a list in the urb completion > handler. A driver level semaphore controls the number of currently > submitting cameras. You can adjust the initial sem_count in > uvc_driver.c. Ideally, that would be a module parameter but I'm just > getting things to work. > > I found capture speeds quite a bit slower than I'd like with this method > though. I can capture with 8 cameras at 10 FPS without overwhelming the > ISO bus but if I change to 15 FPS I can only capture with 3 cameras at a > time. Adding the patch, I then can configure and capture from all 8 > cameras running at 15 FPS but only submitting URBs for 3 at a time. > Depending on how many frames I let those cameras capture I got captured > frame rates from around 4 to 6. > > I'm attaching the patch in case anyone wants to play with this or > suggest ways to improve it.
Interesting approach, but definitely a hack. I'm not sure if it has a chance to make it to the driver. > One thing I had a problem with is that it seems some of the capture images > are corrupted. This patch was against 2.6.27.2. A little old I know but I'm > working on an embedded device. > > 2) I modified ehci-sched.c to not raise the ENOSPC error. That solution > actually lets me capture on all 8 cameras at 15 FPS. This has other > implications though and I'm not sure it is a very good solution. It > does tell me that perhaps the Linux ISO scheduler could perhaps use look > through. One major discrepancy is that bandwidth is allocated based on > the max packet size I think but for my compressed images (MJPG) each > frame is only a fraction of the max allocated bandwidth. That might be the real culprit. Maybe the camera is simply requesting too much bandwidth compared to its real requirements. Can you check whether the video streaming interface has multiple alternate settings ? If so, which one does the uvcvideo driver chose ? You can get the information from the kernel log if you set the UVC_TRACE_VIDEO flag. If the camera request an alternate setting that isn't the smallest, you might try to experiment with hardcoding a lower bandwidth in uvc_video_init. -- Regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
