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
