[wdmaudiodev] Re: Help! Help! MSVAD: passing data from or to the real device
- From: "Zakhar Savushkin" <Savushkin@xxxxxxxxxxxxx>
- To: <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Tue, 26 Sep 2006 17:12:06 +0400
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
Other related posts:
