Categories for Render, Capture and Nodetypes Microphones, Line Connectors and Speakers

In addition to the KSCATEGORY_AUDIO Categories, the INF file can also "decorate" the device driver as having other interfaces that the builder might want to probe.

These can help in directing the builder to probe and fill out a description for the device when making its Audio Endpoint.

For some of these types it attempts to discover abilities and interconnected topologies so that the Endpoint makes better sense to the end user when complete.

Video capture and Audio capture applications typically try to "find" or make sense of the resources of a video capture card by strumming theses "inventories" of endpoints and interfaces when building up a list of choose-able sources and sinks of video and audio data.

Video Capture applications aren't very sophisticated when looking for sources beyond the current year in which they are written.. so a re-think or re-conceptualization of how to present usable resources can lock them out of running properly on newer re-thought operating systems.

"Some" device drivers hook themselves into the default audio or "desktop" when loaded.. some do not.. those that do are easier to support with legacy capture software because they merely have to capture from the default channels of the system.

UVA and UVC seems to be the latest "re-think" in the way video and audio information is presented as a resource to the operating systems and programs. And they are generally across USB serial buses.

Since Analog video capture is mostly long gone.. supporting moving between XP to Vista and 7 or 8 and 8.1 is unlikely to be something that can be done for much longer. Even the device driver signing methods and keepers of the hardware and kernel keys is consolidating at Microsoft.. and locking more and more of the developer community out.. which could lead to an upheaval in computer programming moving forwards.. abandoning Microsoft and Apple products for a more flexible and open system.. unlikely Linux since that too seems to have started blocking flexible development models. A stagnation of original thinking seems to be beginning a new dark age.

Ironically the XP operating system without hardware device driver signing.. is the easiest to develop for.. and the ReactOS may eventually prove to be the favored operating system of the future. Its hard to imagine Microsoft will mentor and shoulder the burden of solving problems for indiscernible and not immediately profitable motives long term.

Why Video Capture boards don't display Audio Endpoints in Vista and 7

I'm real fuzzy on this at the moment.

But it appears when going from XP to Vista, they re-thought how Directsound or Directshow audio devices were presented to programmers.

They invented something called the "audio endpoint builder service" which monitored the PnP insertion of device drivers, registering various characteristics about loaded device drivers in the registry or class tree.

When one added itself to the "KSCATEGORY_AUDIO" class category, it went to work "probing" the "device" attached to the system by inspecting its pins and their default parameters.. automatically constructing an "Audio Endpoint".

These virtual "Audio Endpoints" were conceptually thought to be "better" than using the Directshow API which was based on filters for accessing and manipulating the hardware on a device directly.

Instead, users and programmers were able to "think about" the Audio Endpoint as a fully fleshed out object which they could use more generic commands to control to setup an "Endpoint Session" which was assumed "Blocked" until it was "un-Blocked" and began streaming data, either In or Out of its device.

Once these Endpoints were constructed, they populated the Sound Control panels where they could be designated as the default Playback or default Recording Endpoint.. 

The reason video capture cards do not appear as Audio Endpoints, is apparently because they're device driver INF files do not "decorate" themselves as "KSCATEGORY_AUDIO" class type.. and the "audio endpoint builder service" ignores them and does not build up the Endpoints the Sound Control panels use to populate the choices in the Playback and Recording endpoint choices.

It seems the "pins" for In or Out should also be decorated with descriptions of whether they are WaveOut or WaveIn or some other type.. but mostly the rest of the Directshow description should map to parts of the constructed Endpoints, since the Vista revised "re-conceptualizing" allowed for supporting legacy communications protocols and interfaces.

So.. its possible their devices will just work once their device drivers are revised to carry the badge of "KSCATEGORY_AUDIO"

One potential problem however are "signed" device driver packages.. since they are supposed to come with a .CAT and certificate set that ascertains the device driver has not been tampered with.

It might be possible after the device driver is installed.. to manually patch the registry to "add" the device driver/device to the "KSCATEGORY_AUDIO" by adding its guid.. if thats how it works.. but might also need to do that for its Pins.

Win7 x32 seemed easier to avoid device driver signing problems for a test.. or self signed was at one time possible with Win7 x64