On Mon, Dec 22, 2008 at 01:54:02AM -0500, xxxxx@msn.com wrote:
I'm going to use isousb sample code in WinDDK 6001.18001. I'v read the code,
and it has two methods to read data from USB device in Isochronous IO mode.
One is used IRP_MJ_READ/IRP_MJ_WRITE, the other one is use ISO STREAM method
to read continuous data from the device.
I tend to use STREAM way to get data. Because I want to get data
continuously without any idle. IRP_MJ_READ/IRP_MJ_WRITE will have a little
break between two packages reading.
There may be some confusion here. IRP_MJ_READ and IRP_MJ_WRITE are sent
TO your driver by the applications. The mechanism used between your driver
and the host controller is entirely separate. It is possible to write a
driver that waits until it gets an IRP_MJ_READ and passes that buffer down
to the HCD, but to get maximum throughput, you would have to use
asynchronous I/O and have multiple ReadFiles outstanding at once.
It's also possible for your driver to allocate its own pool of read
requests, and submit them on its own. Then, when the application reads,
you copy the results from the last completed request.
Microsoft recommends that useing KMDF to build new driver. I also find the
USB ISO sample code in WinDDK 6801.0, named usbsamp. The STREAM method
disappear. I need your advice.
KMDF has the concept of a continuous reader for streaming data, but,
unfortunately, it doesn't yet support isochronous pipes.
Aother question, How can I get the stream data in APP program? DirectShow?
or a large share memory between driver and app. Which one is better?
What kind of device is it? If it is a capture device, then you should
write an AVStream driver. Then, AVStream and DirectShow manage the
buffering. If it is a custom device, then you can do whatever is
comfortable. The shared memory scheme is rarely satisfactory; a better
scheme is overlapped I/O, where you submit a number of ReadFile requests
and keep them in rotation.
Tim Roberts, xxxxx@probo.com
Providenza & Boeklheide, Inc.