xxxxx@arbitron.com wrote:
Dear Friends,
I am new to the driver development. I want your help to solve one of my problem.
Question:
I have virtual audio driver running in my XP pc. Right now my virtual audio driver can capture the PCM data and can save it into the .wav file.
Actually my requirement is to put the PCM data in the user space memory which was allocated dynamically ,instead of save it in the file.
Can anyone help me out to do the same? or Is there any simple sample code to understand the user application and kernel mode driver communication.
There are two steps to this. One is contacting the driver, the other is
passing the information.
I *assume* you want to pass this data to a process other than the one
that is generating the data. Otherwise, the problem is trivially easy.
So, first you need to figure out how your monitor app will contact the
driver. There are basically two ways to do that. One way is to use the
KS framework. Add a custom property set to your audio driver. Have
your monitor app load the driver just like a multimedia application by
using the system device enumerator (CLSID_SystemDeviceEnum) and
BindToObject to get an IBaseFilter. From that, you can get an
IKsControl interface and talk to your custom property handlers. You’ll
still have the issue of communicating between the two instances, but
that’s an issue you can figure out.
The other way is to create a separate control device object, like some
of the WDM filter drivers do. Your application would connect directly
to this control device using CreateFile, and send normal ioctls to
communicate with it. Although this seems simpler on the surface, you
need to remember that your KS driver already has dispatch handlers for
the standard device requests. You will have to use trickery to
intercept IRP_MJ_CREATE and IRP_MJ_DEVICE_CONTROL so you can check for
your control device.
I would go the custom property route.
After you get communication established, then you need to worry about
how you are actually passing the data. It’s easy to send in a buffer
and have the audio driver write to it, but what happens when the buffer
fills? Is it circular? Do you just stop writing? Because of timing,
you CANNOT guarantee that your application will stay ahead of the driver.
You have a lot of design decisions to make.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.