[wdmaudiodev] Re: Interfacing Audio Driver From USER MODE

  • From: Matthew Gonzalez <matt@xxxxxxxxxxxxx>
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Sun, 01 Feb 2009 19:26:23 -0800

Yes, you have to add your own handlers after calling PcInitializeAdapter.  You don't have to save the original handler, although that works.  You can simply call PcDispatchIrp if the IRP isn't handled by your code, as discussed in the DDK documentation.


You have to add handlers for create, ioctl, and close IRPs.   You will also need to create your own interface using IoRegisterDeviceInterface.  Your handlers need to distinguish between IRPs meant for  KS and IRPs meant for your interface.  You then use the setup API to find and open your interface.

I've used this method with great success with several different audio drivers.  You can do the same thing with AVStream.

The technique you describe of creating a custom KS property will also work.  As far as what is the "RIGHT" method to use, I'm not sure how you'd make that determination.  Either way, there are a fair number of hoops to jump through.  I always thought that handling KS properties was a pain and hard to debug since KS itself is such a black box.  On the other hand, adding your own ioctl handler means you have to create your own WDM interface, and write code to distinguish between IRPSs meant for your code and IRPs meant for KS/Portcls.

If you add a custom KS property, it's still an ioctl that's being sent to your driver.  It's just being filtered through the KS code.  I'm not sure you'd see a difference in performance.



timr@xxxxxxxxx wrote:
On Sat, Jan 31, 2009 at 06:18:35PM -0800, Vipin Kumar wrote:
i am using a  MSVAD Simple as a base,( so portcls wavecyclic is the

Moreover, as i have told earlier, i have already done
   DriverObject->MajorFunction [IRP_MJ_DEVICE_CONTROL] =

How did you do that?  The DriverEntry for MSVAD, like all port class
devices, calls PcInitializeAdapter.  THAT routine sets up all of the
dispatch entry points for you.  Port class is ALREADY handling IRP_MJ_CREATE.
You can't just override it, because you'll lost the class driver support.

This is a kernel streaming driver.  The KS framework is already opening
and closing your driver, and sending you specially formatted ioctls to
handle the KS interfaces.  You need to work within that framework.

The RIGHT way to do this is to add another custom property to handle
your unique needs.  Then, your application can use CLSID_SystemDeviceEnum
to find your driver and get the IBaseFilter interface.  From there, you can
fetch an IKsControl interface, and send property requests to your heart's

Before I get a possible/impossible reply, I will state that it is possible
for you to intercept IRP_MJ_DEVICE_CONTROL requests on your own, after
port class has done its setup.  You have to save the original 
IRP_MJ_DEVICE_CONTROL handler, so you can forward to it any requests that
you don't recognize.  You still have the problem of how to open the device,
given the KS framework.  Overall, I have to think it would be better for 
you to do this through properties.
****************** WDMAUDIODEV addresses: Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx URL to WDMAUDIODEV page: http://www.wdmaudiodev.com/

Other related posts: