Hi! When I decided to write VAD that will transfer audio streams to and from real HW, I thought it would be easy :-) 'coz everything that I must to implement (in general) - "CopyTo" and "CopyFrom" functions of IMiniportWaveCyclicStream interface. ( It seems to be much easy, then implement audio filter driver (as device upper filter), which process IRPs. I've done this filter driver, but it has a lot of restrictions and cannot be widely used on all hardware) But... there are a lot of problems, though. There are some things you should be aware: It seems that SysAudio (core component of windows audio subsystem) has internal lock (mutex). In some cases you should use asynchronous calls (from another thread, for instance) to the real audio device, because user's call to Your VAD is passed through SysAudio and it could lead to deadlock. BTW, work items not always helpful: For example, user calls waveOutClose() on Your VAD. SysAudio (seems to) grab his mutex and allocates work item, that will send IRP_MJ_CLOSE to Your VAD. PortCls driver process this IRP and calls Release (-> ~ctor) on Your IMiniportWaveCyclicStream object. If You try to close real audio device in this ~ctor, You will have deadlock with Sysaudio mutex. If you try to use work item, it can be queued to the same worker thread (remember, that ~ctor is called from work item) and get deadlock again. Current position, that returned by IMiniportWaveCyclicStream::GetPosition() request should be synchronized with actual position of real audio device. But you cannot query that position (by KSPROPERTY_AUDIO_POSITION request) because GetPosition() is called at DISPATCH_LEVEL But what complicates the issue is the fact that PortCls driver only buffers 30ms of audio data to Your VAD. It asks current position with IMiniportWaveCyclicStream::GetPosition() request and pre-buffers 30ms audio data before that position. This works well in real hardware with DMA, but in "virtual" hardware it leads to choppy sound, especially when CPU load is high. I've done some debuggin' and found that the value of 30ms is hard-written in portcls.sys code, so there is no way to force this driver to buffer more than 30ms. I still looking for solutions of this problem. Hope this will help You :-) Zakhar Savushkin Spirit DSP, www.spiritdsp.com