Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

Is a filter driver appropriate for adding audio support to a WDDM driver?

dbarriedbarrie Member Posts: 28

My understanding is that a single hardware ID can only have one base driver installed, and if it is a PnP driver, can have filter drivers installed above or below it to manipulate things as needed. I am currently using this setup for my toy GPU, where the base WDDM driver is a KMDOD and I have a filter that runs above it which lets me interface with the hardware in ways that are not supported by the KMDOD paradigm.

Audio drivers use a different class than display drivers, and I'm not sure how that interacts with the "one driver (stack) per hardware ID" rule. Can I have drivers of different classes loaded for the same hardware? If not, am I going to have issues related to the fact that I'm trying to implement an audio driver using a filter driver on top of a display driver?

I plan on actually interacting with the hardware solely from the WDDM KMDOD driver, through interfaces exposed by it, exactly as my existing filter driver does to allow for usermode DMA and other things that KMDODs don't support.

I found an open-source WDDM driver ( that uses a similar interface-based communication mechanism between the audio driver and the display driver, but in that example there are different ACPI hardware IDs for the two drivers. In my case, I have a single PCI ID.

Any insight would be appreciated!


  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,828

    congrats on figuring out how to stack your filter on top of the KMDOD driver. If you want to expose audio, you will need
    1. a pnp device in the audio classs
    2. a new driver which will be an audio class mini port driver
    3. a new INF for your audio class device driver

    for 1, your filter driver can enumerate a PDO. You can give it whatever hardware ID you want. The toaster sample has to examples of how to enumerate a PDO. The moufiltr example shows how to enumerate a PDO from a filter.

    for 2, I think there is an audio driver wdk sample, but I don't remember exactly. I am sure Tim has the best guidance here on where to start. once you have the right sample to start from, your new audio driver can query the PDO for whatever interfaces/resources it needs to function. Your KMDOD filter (which enumerated the PDO) will need to be updated to support these interfaces.

    for 3, probably start with the INF from the wdk sample.

  • dbarriedbarrie Member Posts: 28

    Ah ha, that makes a lot of sense! I didn't even think about the fact that a driver could just "create" devices like that, despite it being fairly obvious that this is exactly what the existing bus drivers are already doing. Thanks!

    There is a pretty fully-featured WDM sample driver that I've already started pulling code from, and the concepts there seem pretty simple. I'm fairly certain that the most complex part I'm going to have to figure out (beyond just organizing the code as makes sense for my use-case) is having to add a single enum value to determine which driver the DMA requests are coming from. :smile:

    You mentioned that I can give it whatever hardware ID I want, but are there guidelines on what kinds of IDs are preferable or recommended for this kind of use case? Not that it really matters, this isn't going to be commercialized and I'm already using a PCI vendor ID that I definitely do not own (though it's also not one that's currently assigned), but it would be nice to do things the "right" way!

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,828
    You do not want to write a bus driver with WDM. KMDF is your only sane option. As for the id, use a UUID
  • dbarriedbarrie Member Posts: 28
    edited October 2023

    Is Audio Devices Design Guide not the preferred way to write an audio driver?

    FWIW, I've already got my filter adding a new PDO for the audio "device", and I'm able to load the WDM audio driver scaffold I've written for it. The driver doesn't do much of anything yet, but the infrastructure all seems to connect up and it looks like it'll be doing what I expect once I finish writing it.

    EDIT: I think there might have been some confusion - I meant I'm looking at the fully-featured sysvad WDM audio driver sample to pull code from. My filter driver is using WDF under the KMDF.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 13-17 May 2024 Live, Online
Developing Minifilters 1-5 Apr 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 20-24 May 2024 Live, Online