[wdmaudiodev] Re: White Papers now available

  • From: "Van Mieghem, Dirk" <dvm@xxxxxxxx>
  • To: "'wdmaudiodev@xxxxxxxxxxxxx'" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Sun, 8 Dec 2002 13:56:24 +0100

Well, I'll be damned :)  I figured this all out before and then completely
forgot about it. Microsoft should change nothing, it's all there and the key
component is "KsProxy".

Probably everyone who wrote a WDM/KS driver knows that it's supposed to
register 3 device interfaces, namely KSCATEGORY_CAPTURE, KSCATEGORY_RENDER
and KSCATEGORY_AUDIO. This is usually done in the INF file though. The
states of these interfaces are set when you call PcRegisterSubdevice. KMixer
and all its surrounding stuff is added on top of the KSCATEGORY_AUDIO
interface. What's important is that all 3 interfaces talk the same language
by using the same set of I/O controls.

In the DirectShow world, the device interfaces show up in 3 similar
categories (see GraphEdit), namely "WDM Streaming Capture Devices", "WDM
Streaming Rendering Devices" and "WDM Streaming System Devices". The latter
one being the category that embeds all KMixer functionality. The COM object
that enables a DS application to talk to the kernel interface is KsProxy and
the white paper presented is the user to kernel mode API it uses. This means
that everyone using the white paper is effectively replacing KsProxy, not
exactly the goal that was intended. Both ends of KsProxy are documented,
DirectShow in user mode and AvStream in kernel mode, so why replacing it? If
some application doesn't need KMixer, it uses the Capture and/or Rendering
devices and KsProxy provides the interface.

Any thoughts?

WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe:  mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx


Other related posts: