When you destroy and recreate the filters, do you recreate them with the same
name?
If so, Windows will treat it as the same device returning – in particular, the
old format cache will be reused.
Raise a KSEVENTSETID_Pin / KSEVENT_PINCAPS_FORMATCHANGE event from your
streaming pin to tell Windows that your format support has changed.
https://msdn.microsoft.com/en-us/library/windows/hardware/ff537132(v=vs.85).aspx
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Paul _
Sent: Monday, January 18, 2016 8:39 PM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: Windows 10 variable sample rate support, WDM driver
Thank you for everyone’s feedback.
Our issues are not fixed with the Windows 10 update (10586), and it may be
something we are doing incorrectly, but it had worked in Windows 7 and Windows
8/8.1.
When our driver first starts up, our miniport driver gets asked to create
streams of all possible formats, to see what our driver supports. The only
format we allow to succeed is the current sampling rate our application is set
to. (Like 44.1 kHz) And everything works fine.
Now if the user changes sample rate via our application, our driver will
unregister and destroy the Wave Port driver and the Wave Topology driver, and
then recreate them.
This time the operating system does not ask us to create "NewStream" to see
what format we support, it appears to remember the answers from the first time
we started up the driver, but we want it to forget about the previous supported
formats and ask us again what we support. (Like it did on Windows 7 and Windows
8).
A work around:
If we change the code, so “NewStream” will succeed to create all formats we can
support, and have “KSPROPERTY_PIN_PROPOSEDATAFORMAT” only return true for the
format we are currently supporting, this works, but it does not seem correct
that “NewStream” may be called at other times that are not during
“Initialization” and create streams that we don’t currently support.
Thanks for your help,
Paul
