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.