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? Dirk ****************** 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 URL to WDMAUDIODEV page: http://www.wdmaudiodev.de/