[wdmaudiodev] Behavior of KSEVENT_PINCAPS_FORMATCHANGE in Win 8.1?

  • From: Paul Carter <pcarterx86@xxxxxxxx>
  • To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • 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 
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 
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 - 
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 
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: