In the video world (AVStream), the static data formats report everything you can ever possibly do, and the DataIntersection handler trims that down to the list of things you can do right now. I have not always had the same experience with audio drivers. There do seem to be some hidden assumptions about 2-channel devices, but I was never able to come up with a mental model to describe it.

As always, I would suggest you ask your question on the [wdmaudiodev] list at https://www.freelists.org/list/wdmaudiodev . That's where the cool audio kids hang out, including two members of the Microsoft audio team who have proven to be an incredible resource over the years.

Basically, yes. The WHLK includes instructions on how to create a submission package, which includes your driver files and the test results.

If you have not done this before, however, do not underestimate the level of effort involved. The WHLK is a pain in the rear to setup and configure, and requires two computers (one controller, one client). One you have it configured, the test runs are all automated.

THEN, you have to have the Microsoft Hardware Partner account in order to have a place to submit it, and creating that account requires an EV signing certificate. If you don't have that certificate, that's the first step, and it can take a week to get one.

I don't know what you mean by "reversing driver files".

An extremely ancient, yet still elucidating, explanation appears here: https://www.osronline.com/article.cfm^article=83.htm

When the I/O Manager is providing synchronous service to the user app (regardless of whether the DRIVER completes the request synchronously or not) the I/O Manager blocks in the context of the requesting thread (before returning to the thread's I/O operation function call). Therefore, there's no need for the APC... the requesting thread is just "woken up".

That... and what Mr. Roddy said.

Does that help?

It took a while to find the doc page that describes what special kernel apcs do: https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/how-completion-processing-is-performed
Basically it boils down to "do all the stuff required to be done before the originating user thread can observe the IO results, some of which might just have to be done in the correct process and/or thread context."

My TMH files have always been Foo.TMH, so not sure where the other ones are coming from...Are these "clean" project files (i.e. not upgraded)?

The times might be a changing (and they are but quite obviously not in a good way) , as long as the driver goes through the documented procedures, the bus logical address is going to meet the device requirements, IOMMU or no IOMMU, and how that happens is a problem only for the HAL.

Yeah but we still haven't finished arguing about this. :-)

In the Enum registry key for your device, there will be values for UpperFilters and LowerFilters. This is a REG_MULTI_SZ value that includes the list of the service names of the filter drivers for this device. Once you have a service created, you can add your service name to this list.