How to porting USB WebCarmera minidriver to AVStream?

Hi All,

My old minidriver is based on streaming class and I want to port it to
AVStream. I have looked over AVStream sample code in DDK. I find it is
very different from class minidriver. In AVStream sample I can find few
operation communicating with HW, I don’t understand how AVStream
minidriver control my usb device? And also, the two samples is installed
as a Media class device in system, I am not sure whether AVStream device
‘must belong’ Media class or not?

Does anybody have samples, guidelines or any advice to me? Thanks a lot.

Best Regards,

Dengwen

xxxxx@sunmedia.com.cn wrote:

My old minidriver is based on streaming class and I want to port it to
AVStream. I have looked over AVStream sample code in DDK. I find it is
very different from class minidriver. In AVStream sample I can find
few operation communicating with HW, I don’t understand how AVStream
minidriver control my usb device? And also, the two samples is
installed as a Media class device in system, I am not sure whether
AVStream device ‘must belong’ Media class or not?

Does anybody have samples, guidelines or any advice to me? Thanks a lot.

An AVStream driver doesn’t have to be media class, but that’s almost
always the right choice.

Is your current driver based on USBCAMD? If so, then I see absolutely
no reason to change your architecture at this point. As you note, there
are no USB-based AVStream samples. Although it isn’t rocket science to
yank the PCI manipulation out of avshws and replace it with USB
requests, I think it is unnecessary. USBCAMD is targetted directly at
USB capture devices, and it works. It’s hard to argue with that.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Tim wrote:

Is your current driver based on USBCAMD? If so, then I see absolutely
no reason to change your architecture at this point. As you note, there
are no USB-based AVStream samples. Although it isn’t rocket science to
yank the PCI manipulation out of avshws and replace it with USB
requests, I think it is unnecessary. USBCAMD is targetted directly at
USB capture devices, and it works. It’s hard to argue with that.

Thanks Tim. Yes, of course our driver running on USBCAMD. I heard some
voice that USBCAMD would work in future windows OS but it can’t pass DTM
any more. That’s why we consider porting our driver to AVStream. I don’t
know if it is real? On the other hand, we also want to try new features in
AVStream. So could you give me some advice in replace PCI manipulation?

Best Regards,

Dengwen

xxxxx@sunmedia.com.cn wrote:

Thanks Tim. Yes, of course our driver running on USBCAMD. I heard some
voice that USBCAMD would work in future windows OS but it can’t pass
DTM any more. That’s why we consider porting our driver to AVStream. I
don’t know if it is real? On the other hand, we also want to try new
features in AVStream. So could you give me some advice in replace PCI
manipulation?

I have never heard any plans to eliminate USBCAMD. After all, it is
just a library that helps build a stream-class driver (which is mostly
what AVStream is), and stream-class drivers aren’t going away any time soon.

In fact, in the history of NT, I don’t think Microsoft has ever
eliminated a driver model.

You can figure out in the samples where to do your device initialization
– where to fetch the descriptors and set up your pipe structures. You
can figure out from the state transitions where to change the alternate
interface to enable your iso endpoint and start streaming. That’s the
point where you’ll queue up isoch requests to start the
submit/complete/resubmit loop. You can treat the completion routine
just like the DMA interrupt callback in the samples; that’s where you
actually get your data and copy it to the stream leading edge. You’ll
shut down streaming in the state transition away from “run” mode.

But, in my opinion, it’s not worth it. Stick with USBCAMD.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Tim worte:

You can figure out in the samples where to do your device initialization
– where to fetch the descriptors and set up your pipe structures. You
can figure out from the state transitions where to change the alternate
interface to enable your iso endpoint and start streaming. That’s the
point where you’ll queue up isoch requests to start the
submit/complete/resubmit loop. You can treat the completion routine
just like the DMA interrupt callback in the samples; that’s where you
actually get your data and copy it to the stream leading edge. You’ll
shut down streaming in the state transition away from “run” mode.

It seems many works need to do. Thanks Tim, I wil discuss with my boss if
we really need avstream.

Best Regards,

Dengwen