Hi Dennis,
On Tuesday 27 April 2010 18:19:01 Dennis Muhlestein wrote:
> On 04/27/2010 05:48 AM, Paulo Assis wrote:
> > 2010/4/27 Ian Latter<ian.lat...@midnightcode.org>:
> >>> You can grab frames at whatever speed you want, but it's the camera
> >>> framerate that will make a difference in the usb bandwidth and not the
> >>> amount of frames you get with your application.
> >>
> >> So, if you don't take a frame from the UVC driver, it will simply
> >> continue to refresh an internal buffer with new frames from the camera
> >> device?
> >
> > Think of it like this, the necessary bandwidth is requested by the device
> > and it will depend on the compression, resolution and framerate, in fact I
> > think some ("buggy") devices will always request the maximum bandwidth
> > causing problems on initialization, for these devices I think uvcvideo
> > uses it's own algorithm to calc the necessary bandwidth.
That's right. The uvcvideo driver tries to compute an estimate of the required
bandwidth. That only works for uncompressed formats.
> Do the number of URBs have any effect at all? I made an initial attempt
> to check this a while back by recompiling the driver with UVC_URBS as 1
> or 2 instead of 5.
Not on the bandwidth, no. The number of URBs will influence the memory used by
the driver, and the real-time requirements. The less URBs, the fastest the
driver needs to process the complete URBs and resubmit them to avoid running
out of them.
> Changed the MAX_ISO_PACKETS a lot smaller too.
The number of packets influences the URB size for isochronous transfers. URBs
complete when the maximum of packets have been transmitted. The larger the
number, the less frequent the driver gets interrupted to process URBs (but it
will also have to process more packets in one go, making the processing a bit
longer).
> I wanted to see if perhaps submitting less URBs would somehow lessen the
> bandwidth requirements. It didn't fix the problem though.
The driver explicitly selects the bandwidth by switching to an alternate
setting. The USB core allocates the bandwidth when the URB are submitted, so
the alternate setting selection call might succeed and the URB submission fail
later. Please note that, with USB 3.0, the xHCI driver will perform the
allocation when selecting the alternate setting.
The driver choose the alternate setting with the lowest bandwidth compatible
with the bandwidth requirements reported by the camera. The number of URBs or
packets will have no influence there.
> I suspect that somewhere in an underlying layer, whether kernel or physical,
> something is checking that bandwidth requirement for the configured
> endpoints and then denying new URBs being submitted. I'm not opposed to
> modifying something at a lower level but I haven't found the spot at this
> point. I guess if the error comes from the physical hub there isn't much to
> be done then.
The USB core checks the bandwidth. There's an allocation process defined by
the USB standard, and there's pretty much no way around that. You could modify
the EHCI host controller driver to allow more than 80% of the total bandwidth
to be allocated to periodic transfers. Another solution, as you pointed out
below, is not to submit the URBs. That's very similar to performing the
STREAMON/QBUF/DQBUF/STREAMOFF sequences in userspace on all devices one after
the other, except that you might be able to get slightly better performances
by avoiding context switches.
> > Also the device will always try to dispatch frames at the requested
> > framerate, if you don't grab them they will simply be dropped by the
> > driver.
>
> I wonder if there is some way to restrict URB submitting to around 10
> fps? Perhaps a semaphore on the number of cameras that can be submitting
> URBs at all. If I go ahead and configure all the cameras to run at 15 fps
> but only submit URBs for say 3 of the cameras at a time it seems it would
> work. I'm not worried about dropping 1/3 of the frames.
That might work, but it would be quite hackish. You wouldn't be able to
synchronize to the frame start, so you will loose half a frame on average
every time you "start" a camera.
You would basically need to keep a list of cameras and handle them in a round-
robin way. When one of the cameras completes a frame, you will have to stop
submitting URBs for it, wait until all URBs have completed, and submit the
URBs for the next camera in the list.
> I don't think I can write them all out to storage fast enough anyway.
> (I can come close to keeping up with 10 fps on 8 cameras though.)
--
Regards,
Laurent Pinchart
_______________________________________________
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
