xxxxx@yahoo.com wrote:
I have a problem about usb video class. You konw the USB transmition is lauched by the host.
So, the camera sensor can not send video data to host at any time and noly wait the host to ‘read’ its data.
Then the host caculates the IN package numbers per USB frame (acording to the descpritor returned by camera) and send IN tokens. Right?
Sort of. The format negotiation for a UVC camera happens in a sequence
of requests called “probe/commit”. The host sends a series of “probes”
until it find a format it likes, then it sends a “commit” to choose it.
One of the fields in the probe/commit request is
“dwMaxPayloadTransferSize”. For an isochronous device, usbvideo.sys
uses that value to choose an appropriate alternate setting.
The endpoint descriptor for the chosen alternate setting determines how
the transfer request URBs must look. Each packet in the URB must equal
the maximum transfer in a single microframe, and each URB must span a
whole number of frames. So, for example, if I have the maximum possible
high-speed device, with a max packet size of 1024 x 3 transfers per
microframe, with an interval of 1, then each URB must contain a multiple
of 8 packets of 3072 bytes each.
For a bulk endpoint, usbvideo simply makes a single request large enough
for a frame. The host controller will divide that request up into
packets that match the endpoint descriptor size, and send IN tokens
until the request is filled.
Dose the host sent the IN tokens the exact number or more?
For an isochronous pipe, the number of transfers is specified by the
endpoint descriptor. In my maximum example above, the host will send up
to 3 IN tokens in each microframe, as long as there is an empty “read”
request pending. (If the device does not respond to the 1st, it won’t
send the rest.)
For a bulk pipe, the host controller will send IN tokens continuously,
as long as there is an empty “read” request pending. As soon as there
are no requests waiting, IN tokens will stop.
What are the diffrences between BULK and ISOC endpoints when send there IN tockens?
You need to read the USB specification to understand this. The spec is
surprisingly readable, in my opinion. If you are considering building a
UVC device, you also need to fetch and understand the USB Video Class
specifications.
Who determine the number of IN tokens? The uvc driver or the usb bus driver in Windows?
The USB host controller hardware determines when to send the IN tokens,
based on a schedule that is laid out by the host controller driver. The
host controller driver schedules each frame in advance based on the
endpoint types, the endpoint descriptors, and whether there are requests
waiting. It’s important to remember that, even for an isochronous
endpoint where bandwidth is reserved, the host controller will never
send an IN token unless there is an empty read request that has been
submitted from a client driver.
How large the camera buffers we need?
Are you asking this from the standpoint of the camera hardware, or from
the standpoint of the client driver? Partly, your decision has to be
based on clock rates. I have one client where the camera runs at an
NTSC clock rate (about 27 MHz). Because of sync and blank intervals,
the long-term average data rate would fit into an isochronous endpoint,
but while a scanline is being transferred, the burst data rate exceeds
that of the bus, and buffering has been a continuous problem.
There is a tendency to want to minimize the size of the buffering in the
camera hardware, to reduce cost. This usually ends out being a
problem. In an isochronous pipe, you are guaranteed one transfer per
microframe, but the spec does NOT guarantee that the transfer occurs at
the same instant every time. Thus, you have to be able to hold at least
2 microframes worth of data.
With a bulk pipe, you need even more, because you are competing for
bandwidth with other devices. If someone plugs in a USB flash drive and
copies a file, your bandwidth is going to go down.
I suggest that every camera have room to store a complete frame, but I
understand that’s a LOT of memory for a small device.
I have brown roughly the linux uvc driver. I fine the uvc dirver just send some URBs and sleep for data. How about windows?
That’s the way ALL USB client drivers work.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.