[wdmaudiodev] Re: Behavior of KSEVENT_PINCAPS_FORMATCHANGE in Win 8.1?
- From: Paul Carter <pcarterx86@xxxxxxxx>
- To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Tue, 17 Dec 2013 18:43:25 -0800
Update: The unknown GUID messages have gone away since deleting and re-defining
my format-change helper function (not sure why), however remaining questions
are still there:
I don't see an assumed triggering of either DataRangeIntersection or
PropertyHandlerWaveProposeDataFormat 'GET' case after adding the format change
event trigger calls (as per the Win 7 examples in the document mentioned
previously) - and when I did see PropertyHandlerWaveProposeDataFormat GET case
called it appears not to be as a result of trying to trigger format change
myself and it received a NULL target data pointer.
So I'm trying to understand - does KSEVENT_PINCAPS_FORMATCHANGE work in Win
8.1? and what do I expect to see after the event is added (after
AddEventToEventList call).Anything I can do to confirm the event is seen by
Windows other than wait for a call to either DataRangeIntersection or
PropertyHandlerWaveProposeDataFormat with 'GET' case?
Thanks for any help/pointers,Paul Carter.
From: pcarterx86@xxxxxxxx
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Behavior of KSEVENT_PINCAPS_FORMATCHANGE in Win 8.1?
Date: Mon, 16 Dec 2013 10:23:48 -0800
Hello,My first posting to this list - I hope I am doing this the right way,
hope this is not too long.
I'm very new to windows drivers programming however I'm trying to debug some
existing code - audio mini-port driver - in order to correct an issue with
audio format change. The driver I'm working on is compiled for Windows 8.1 64
bit.
The remote device (Bluetooth headset and mic) can change it's sample rate from
8KHz to 16Hz or vice versa each time an audio link (SCO/eSCO) is started (after
initial pairing/driver instance load), however the original code I am working
with can only work with the first sample rate/audio format selected after
'DataRangeIntersection' is called (our proprietary implementation selects the
matching format/sample rate - dependent on the remote device's current mode
found via codec negotiation over the BT link).
I looked around on various forums/msdn and found the document "Windows 7
Changes Related to Audio Drivers', and followed the example for using
KSEVENT_PINCAPS_FORMATCHANGE, however I'm not getting what I expected as a
result.
I've added the appropriate EventHandlers, EventTable, AutomationTable and added
that to the miniport filter descriptor (this has been peer reviewed and appears
to be correct).I've added my equivalent 'GenerateFormatChangeEvent' helper
function 'FormatChange' which I call on detection of the remote device format
change before it tries to start the audio link.When I call the FormatChange
helper function to call GenerateEventList - it appears to get called ok however
I am seeing in my debug-trace logs an unexpected 'Unknown GUID' message:
00001506 ibt_hfp 4 5716 4 1506 12\02\2013-14:51:05:906
** Calling UpdateFormat ** 00001507 ibt_hfp 4 5716 4 1507
12\02\2013-14:51:05:906 Unknown( 191):
GUID=a941a450-b8a4-8abf-c03f-b115b0ff236e (No Format Information found).
I searched the GUID but couldn't find anything matching, and besides it
appeared to be different at different times I installed and tested the driver -
e.g:
00002100 ibt_hfp 4 6732 5 2100 12\02\2013-14:26:36:833
** Calling UpdateFormat ** 00002101 ibt_hfp 4 6732 5 2101
12\02\2013-14:26:36:833 Unknown( 189):
GUID=e664c8d2-061b-bf8f-6b9f-590726125f0b (No Format Information found).
When I remove the call to this function, but put the same 'generateEventList'
calls into the existing 'UpdatePinStatus' (which already adds
KSEVENT_PINCAPS_JACKINFOCHANGE events), this error message goes away.
So my first question is why this message would get triggered by adding a helper
function which followed the same code format as UpdatePinStatus, further, I
added a function called 'UpdatePinDescriptor' following the example of the MS
document, and calling this from the same place I was trying to call
'FormatChange' does not cause any error (for the record I made the Pin
Descriptor change code simply update the pins in question with the same
descriptor currently - although I was thinking I might need to force them to
have the same MAX/MIN sample rates based on the current audio mode to solve my
problem potentially).
My second question is on exactly what behavior should I expect when the
FormatChange helper function is called and properly triggers the
FormatChangeEventHandler (via main wave event handler) and after that calls
AddEventToEventList (for KSEVENT_PINCAPS_FORMATCHANGE VERB_ADD case); It was
not clear to me from the MS document/MSDN if I should expect a call to the
DataRangeIntersection handler (which doesn't appear to be the case) or just the
'PropertyHandlerWaveProposeDataFormat' function - where I have added the code
for handling the KSPROPERTY_TYPE_GET case - but where in my logs I am seeing
that the passed in property request pointer is always NULL when that case is
triggered (so I cannot update the format there).It's also not clear from my
logs that the 'PropertyHandlerWaveProposeDataFormat' GET case was actually
triggered as a direct result of AddEventToEventList for the format change
events - should that be the case? Since I added the FormatChangeEventHandler
I've also seen that it gets called with the 'VERB_ADD' case independently from
any calls I made to that helper function too (before DataRangeIntersection is
called) - is that to be expected?
I appreciate any response on my questions - thanks,Best regards,
Paul Carter.
Other related posts:
