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 (https://www.nxp.com/design/software/embedded-software/i-mx-software/windows-10-iot-enterprise-for-i-mx-applications-processors:IMXWIN10IOT) 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!
congrats on figuring out how to stack your filter on top of the KMDOD driver. If you want to expose audio, you will need
- a pnp device in the audio classs
- a new driver which will be an audio class mini port driver
- 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.
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. 
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!
You do not want to write a bus driver with WDM. KMDF is your only sane option. As for the id, use a UUID
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.