[wdmaudiodev] Re: How to support IMiniportAudioSignalProcessing in WaveCyclic based audio driver?

  • From: Danny <dangxhfromuestc@xxxxxxxxx>
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Wed, 22 Jan 2014 19:01:01 +0800

Sorry for the confusion of BSOD. I'll debug it later.

The remaining questions are: 1) Is it possible or necessary switch the
project to WaveRT?   2) the audio path in my driver is
 wavecyclic->physical connection ->topology.  Do I need to add
IMiniportAudioSignalProcessing  support  in Topology filter ?

Thanks.


2014/1/22 Gaurav Khuntale <gauravkhuntale@xxxxxxxxx>

> Hi Danny,
>
> Thanks for the help. I will check out the link you mentioned.
>
> Thank you,
> Gaurav
>
>
> On Wed, Jan 22, 2014 at 11:47 AM, Danny <dangxhfromuestc@xxxxxxxxx> wrote:
>
>> Hi, Gaurav:
>> Yes, it support KSPROPERTY_JACK_DESCRIPTION property.
>> I used SYSVAD sample as the start learning point of how to implement it.
>> http://code.msdn.microsoft.com/windowshardware/slate-system-virtual-audio-f241062f
>>
>> Please post your further question on another thread ;)
>>
>> Hi, Matthew:
>> That is, what is the layer below you? That should determine your choice
>> of WaveCyclic or WaveRT.
>> ==>The layer below is windows 8 Bluetooth stack. PCM data will be encoded
>> and send out via Bluetooth stack. Is it possible and necessary switch the
>> project to WaveRT?
>>
>> Yes, I've modified the code according to SYSVAD. but it keeps BSOD in
>> CMiniportWaveCyclicMSVAD::GetDescription.
>> I guess I've missed something.
>>
>>
>>
>> class CMiniportWaveCyclic :
>> public CMiniportWaveCyclicMSVAD,
>>  public IMiniportWaveCyclic,
>> public IMiniportAudioSignalProcessing,
>>  public CUnknown
>> {
>> public:
>> DECLARE_STD_UNKNOWN();
>> DEFINE_STD_CONSTRUCTOR(CMiniportWaveCyclic);
>>  ~CMiniportWaveCyclic();
>>
>> IMP_IMiniportWaveCyclic;
>> IMP_IMiniportAudioSignalProcessing;
>> ....
>> }
>>
>>
>>
>>
>> //=============================================================================
>> STDMETHODIMP_(NTSTATUS)
>>
>> /* */
>> CMiniportWaveCyclic::NonDelegatingQueryInterface(IN REFIID Interface, OUT
>> PVOID* Object)
>> {
>> PAGED_CODE();
>>
>> ASSERT(Object);
>>
>> if (IsEqualGUIDAligned(Interface, IID_IUnknown))
>> {
>> *Object = PVOID(PUNKNOWN(PMINIPORTWAVECYCLIC(this)));
>>  }
>> else if (IsEqualGUIDAligned(Interface, IID_IMiniport))
>> {
>>  *Object = PVOID(PMINIPORT(this));
>> }
>>     else if (IsEqualGUIDAligned(Interface,
>> IID_IMiniportAudioSignalProcessing))
>>     {
>>         *Object = PVOID(PMINIPORTAudioSignalProcessing(this));
>>     }
>> else if (IsEqualGUIDAligned(Interface, IID_IMiniportWaveCyclic))
>>  {
>> *Object = PVOID(PMINIPORTWAVECYCLIC(this));
>> }
>>  else
>> {
>> *Object = NULL;
>> }
>> ...
>> }
>>
>> NTSTATUS
>> CMiniportWaveCyclic::GetModes
>> (
>>     IN     ULONG     Pin,
>>     OUT    GUID*     SignalProcessingModes,
>>     IN OUT ULONG*    NumSignalProcessingModes
>> )
>> {
>> ...
>> }
>>
>>
>>
>> KMODE_EXCEPTION_NOT_HANDLED (1e)
>> This is a very common bugcheck.  Usually the exception address pinpoints
>> the driver/function that caused the problem.  Always note this address
>> as well as the link date of the driver/image that contains this address.
>> Arguments:
>> Arg1: c0000005, The exception code that was not handled
>> Arg2: adff1a74, The address that the exception occurred at
>> Arg3: 00000001, Parameter 0 of the exception
>> Arg4: 00000000, Parameter 1 of the exception
>>
>> WARNING: Stack unwind information not available. Following frames may be
>> wrong.
>> a9b8a2e0 81209048 0000001e c0000005 adff1a74 nt+0x1061b4
>> a9b8a2fc 8117a532 a9b8a828 8125f1c0 a9b8a3f0 nt+0x1ab048
>> a9b8a320 8117a504 a9b8a828 8125f1c0 a9b8a3f0 nt+0x11c532
>> a9b8a3e0 8108425b a9b8a828 a9b8a3f0 00010037 nt+0x11c504
>> a9b8a80c 81176036 a9b8a828 00000000 a9b8a900 nt+0x2625b
>> a9b8a878 8117887b 00000000 00000000 00000000 nt+0x118036
>> a9b8a900 adff1a74 badb0d00 0123a3d0 ad044880 nt+0x11a87b
>> a9b8a974 adff23f2 b229d330 00000000 a9b8a9b0
>> MyDriver!CMiniportWaveCyclicMSVAD::GetDescription+0x36
>> [.\source\basewave.cpp @ 146]
>> a9b8a984 8a5ccb9f b229d320 00000000 00000000
>> MyDriver!CMiniportWaveCyclic::GetDescription+0xc [.\source\minwave.cpp @
>> 295]
>> a9b8a9b0 8a5cccc2 9069c9b0 8c872160 b229d320 portcls+0x17b9f
>> a9b8a9c4 8a5cc759 8c872160 00000001 87175688 portcls+0x17cc2
>> a9b8a9e0 8a5cc831 a9d4d924 00000020 870f9538 portcls+0x17759
>> a9b8aa00 8a90a2b5 00000000 870f9538 00000000 portcls+0x17831
>> a9b8aa64 8a90a72a 00000028 a9d4d924 00000001 ks+0x122b5
>> a9b8aa80 8a5ca812 87175688 00000004 a9d4d8e8 ks+0x1272a
>> a9b8aa9c 8a5dd5a0 b1de0e70 0069c9b0 00000004 portcls+0x15812
>> a9b8aadc 8a5ca3e5 9069c998 ad396cb0 87175688 portcls+0x285a0
>> a9b8ab10 8a90a664 ad396cb0 00000002 87175688 portcls+0x153e5
>> a9b8ab2c 8a5ca03c ad396cb0 87175688 ad396cb0 ks+0x12664
>> a9b8ab5c 8a5ca299 a9b8ab98 adfd993c ad396cb0 portcls+0x1503c
>> a9b8ab64 adfd993c ad396cb0 87175688 00000000 portcls+0x15299
>> a9b8ab98 810cc63f ad396cb0 87175688 00000103 MyDriver!DispatchIoctl+0xc12
>> [.\source\adapter.cpp @ 1255]
>> a9b8abb4 812f09de 87175884 87175688 00000003 nt+0x6e63f
>> a9b8ac10 812f6028 ad0cdb30 00000000 82376a01 nt+0x2929de
>> a9b8acb8 812f502e 00000000 00000000 00000204 nt+0x298028
>> a9b8ace4 811752f7 00000b18 00000000 00000000 nt+0x29702e
>> a9b8ad14 7715f934 badb0d00 02000000 00000000 nt+0x1172f7
>> a9b8ad18 badb0d00 02000000 00000000 00000000 0x7715f934
>> a9b8ad1c 02000000 00000000 00000000 00000000 0xbadb0d00
>> a9b8ad20 00000000 00000000 00000000 00000000 0x2000000
>>
>>
>> STACK_COMMAND:  kb
>>
>> FOLLOWUP_IP:
>> MyDriver!CMiniportWaveCyclicMSVAD::GetDescription+36
>> [.\source\basewave.cpp @ 146]
>> adff1a74 8908            mov     dword ptr [eax],ecx
>>
>> FAULTING_SOURCE_LINE:  .\source\basewave.cpp
>>
>> FAULTING_SOURCE_FILE:  .\source\basewave.cpp
>>
>> FAULTING_SOURCE_LINE_NUMBER:  146
>>
>> FAULTING_SOURCE_CODE:
>>
>>    145:
>> >  146: *OutFilterDescriptor = m_FilterDescriptor;
>>    147:
>>    148: return STATUS_SUCCESS;
>>    149: } // GetDescription
>>    150:
>>
>>
>>
>> Thank you.
>>
>>
>> 2014/1/22 Matthew van Eerde <Matthew.van.Eerde@xxxxxxxxxxxxx>
>>
>>>  In particular, implement IMiniportAudioSignalProcessing::GetModes, and
>>> respond to QueryInterface for IID_IMiniportAudioSignalProcessing, and
>>> portcls will call into your GetModes() method. This should work even though
>>> you are WaveCyclic and not WaveRT.
>>>
>>>
>>>
>>> The relevant code in
>>> http://code.msdn.microsoft.com/windowshardware/slate-system-virtual-audio-f241062f/sourcecode?fileId=86816&pathId=1882676779is:
>>>
>>>
>>>
>>> // minwavert.h
>>>
>>> class CMiniportWaveRT :
>>>
>>>     public IMiniportWaveRT,
>>>
>>>     public IMiniportAudioEngineNode,
>>>
>>>     public IMiniportAudioSignalProcessing,
>>>
>>>     public CUnknown
>>>
>>> …
>>>
>>>
>>>
>>>     IMP_IMiniportAudioSignalProcessing;
>>>
>>>
>>>
>>> // minwavert.cpp
>>>
>>>
>>>
>>> STDMETHODIMP_(NTSTATUS)
>>>
>>> CMiniportWaveRT::NonDelegatingQueryInterface
>>>
>>> …
>>>
>>>     else if (IsEqualGUIDAligned(Interface,
>>> IID_IMiniportAudioSignalProcessing))
>>>
>>>     {
>>>
>>>         *Object = PVOID(PMINIPORTAudioSignalProcessing(this));
>>>
>>>     }
>>>
>>>
>>>
>>> …
>>>
>>>
>>>
>>> NTSTATUS
>>>
>>> CMiniportWaveRT::GetModes
>>>
>>> (
>>>
>>>     _In_                                        ULONG     Pin,
>>>
>>>     _Out_writes_opt_(*NumSignalProcessingModes) GUID*
>>> SignalProcessingModes,
>>>
>>>     _Inout_                                     ULONG*
>>> NumSignalProcessingModes
>>>
>>> )
>>>
>>>
>>>
>>> *From:* wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:
>>> wdmaudiodev-bounce@xxxxxxxxxxxxx] *On Behalf Of *Matthew van Eerde
>>> *Sent:* Tuesday, January 21, 2014 8:01 AM
>>> *To:* wdmaudiodev@xxxxxxxxxxxxx
>>> *Subject:* [wdmaudiodev] Re: How to support
>>> IMiniportAudioSignalProcessing in WaveCyclic based audio driver?
>>>
>>>
>>>
>>> Yes, the WaveCyclic miniport model supports
>>> IMiniportAudioSignalProcessing.
>>>
>>>
>>>
>>> What do you do with the audio data once you get it? That is, what is the
>>> layer below you? That should determine your choice of WaveCyclic or WaveRT.
>>>
>>>
>>>
>>> *From:* wdmaudiodev-bounce@xxxxxxxxxxxxx [
>>> mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx<wdmaudiodev-bounce@xxxxxxxxxxxxx>]
>>> *On Behalf Of *Danny
>>> *Sent:* Tuesday, January 21, 2014 1:28 AM
>>> *To:* wdmaudiodev@xxxxxxxxxxxxx
>>> *Subject:* [wdmaudiodev] How to support IMiniportAudioSignalProcessing
>>> in WaveCyclic based audio driver?
>>>
>>>
>>>
>>> Hello, my driver is a virtual sound driver based on WaveCyclic. It
>>> worked fine on Windows 8, but during WHCK KsPosition test, the test fails
>>> with the following error message.
>>>
>>>
>>>
>>> *Message*
>>>
>>> 12/6/2013 2:10:26.125 PM
>>>
>>> Failed to query for basic support
>>> KSPROPERTY_AUDIOSIGNALPROCESSING_MODES: Last error:1170
>>>
>>>
>>>
>>> Can I add support for IMiniportAudioSignalProcessing in WaveCyclic based
>>> audio driver?
>>>
>>>
>>>
>>> I've noticed that the new WDK sample SysVad
>>> support IMiniportAudioSignalProcessing property. But it was based on
>>> WaveRT.
>>>
>>>
>>>
>>> Or should I change my project to WaveRT based example? Does WaveRT works
>>> for virtual sound driver? (We don't have the codec hardware, just to
>>> capture the pcm audio data and send out to another stack.)
>>>
>>>
>>>
>>>
>>>  Thank you!
>>>
>>> --
>>> Danny
>>>
>>
>>
>>
>> --
>> Danny
>>
>
>


-- 
Danny

Other related posts: