I have written a virtual usb hub/controller and all transfer modes work except for isochronous.
Im currently testing with a webcam. The usbvideo driver loads correctly when the camera is plugged in and it begins by sending about 9 isochronous URB’s to the hub. Which i then pass on to the actual device remotely.
I fill in each ISO urb in the remote server, as it comes in, with video data from the real webcam and pass it back to the client and complete the WdfRequest. However looking at the camera output on the client using Windows Explorer (USB Video Device), it never seems to render the image. Its as if its waiting for something to finish except i have confirmed that all the iso urbs are all filled in in-order and returned with data. I have run xp in debug mode and done a ctrl-break and found that the following routines are waiting on an IRP at any one time:
usbvideo!USBVideoInterruptCompletion
and
usbvideo!CaptureCompleteCallbackIsoch (quite a few pending IRPS are from this routine)
I have a feeling i need to be completing the isochronous requests in a certain order, i am currently just filling them in one at a time as they come in, I suspect usbvideo is doing a WaitForMultipleObjects or something similar.
Does anyone know what order to fill in the isochronous urb’s?
Thanks,
Michael
xxxxx@gmail.com wrote:
I have written a virtual usb hub/controller and all transfer modes work except for isochronous.
Im currently testing with a webcam. The usbvideo driver loads correctly when the camera is plugged in and it begins by sending about 9 isochronous URB’s to the hub. Which i then pass on to the actual device remotely.
9 URBs? Really? I’m surprised by that. USBAudio.sys, for example,
only sends 2. Are all 9 for the same endpoint? Why would there be 9,
instead of a nice power of 2?
I have a feeling i need to be completing the isochronous requests in a certain order, i am currently just filling them in one at a time as they come in, I suspect usbvideo is doing a WaitForMultipleObjects or something similar.
Well, you should be able to tell that from the call stack. Which
routine is it blocking in?
Does anyone know what order to fill in the isochronous urb’s?
USBVideo devices can have an interrupt endpoint for returning status
information. Are you seeing interrupt requests as well as isochronous?
The name “USBVideoInterruptCompletion” leads me to think you are.
Are you copying the information from the ISO_PACKET array? Isochronous
requests are handled differently from bulk and interrupt requests.
I’m dubious that you will be able to make this work reliably. Video
cameras operate in real time, and in many of the cameras I’ve dealt
with, the latency tolerances are very tight. If the process is delayed,
FIFOs overflow and badness ensues.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
When a (USBVIDEO class 1.0 compatible) webcam is first plugged in, after the usual descriptor requests and configuration/interface selection, the usbccgp.sys driver sends a single interrupt URB to the camera endpoint. The usbccgp.sys driver then sends 9 ISO URBs simultaneously (each 393216 bytes (3 * 1024) * 128 packets) to the same camera isochronous (IN) endpoint. The usbhub.sys then begins filling the ISO URBs with image data. As each ISO is filled in sequence and completed, another one is generated by the usbccp.sys and send to the hub. The initial and only interrupt URB sent previously is never completed until the webcam is disconnected. This is all using the standard built-in windows drivers (which of course work). I’m guessing there are 9 sent initially so that there is plenty of space for the hub to fill the isos if the upstream drivers are slowed by other processing activities of the system (Im assuming those URBs are sitting in the hub hardware memory in some form waiting for filling).
So when i start my virtual hub driver, it behaves exactly the same way i can watch the URBs in/out of my driver and for comparison, on my other machine setup watch the same URB’s in/out of the built-in windows drivers. I know it is possible to stream ISO urbs over a network as i have seen other products do this.
Anyway i will post here when i figure out the answer incase anyone else is stuck also
xxxxx@gmail.com wrote:
When a (USBVIDEO class 1.0 compatible) webcam is first plugged in, after the usual descriptor requests and configuration/interface selection, the usbccgp.sys driver sends a single interrupt URB to the camera endpoint. The usbccgp.sys driver then sends 9 ISO URBs simultaneously (each 393216 bytes (3 * 1024) * 128 packets) to the same camera isochronous (IN) endpoint.
Well, it’s not usbccgp.sys. It’s usbvideo.sys. The URBs pass THROUGH
usbccgp.sys, but they do not originate there.
The usbhub.sys then begins filling the ISO URBs with image data. As each ISO is filled in sequence and completed, another one is generated by the usbccp.sys and send to the hub. The initial and only interrupt URB sent previously is never completed until the webcam is disconnected.
…or unless the camera has some status information to send. The
interrupt endpoint is a little-used part of the usbvideo spec.
And, of course, it’s not really usbhub.sys that does the filling. The
URBs go down into the host controller, and the memory is sent in a queue
to the host controller hardware. The buffers are filled via DMA.
So when i start my virtual hub driver, it behaves exactly the same way i can watch the URBs in/out of my driver and for comparison, on my other machine setup watch the same URB’s in/out of the built-in windows drivers. I know it is possible to stream ISO urbs over a network as i have seen other products do this.
For certain cameras, sure. But I have worked on cameras where the
buffering is very delicate, so that a delay of a few hundred
microseconds was enough to let the hardware FIFOs overflow. You’d have
a tough time with something like that.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.