I Also faced similar issue on Windows 8.1 and later os. My analysis
revealed that format change event in the os does not erase the cached
value.
On Feb 5, 2016 4:22 PM, "Neetu Sand" <neetu.freelist@xxxxxxxxx> wrote:
Hi,
I saw this post and noticed that Paul has mentioned link to one of my
posts . We are still running into this issue on Windows 10 build 10240.
Matthew, I have captured a recording as you suggested above and is
attached with this email. Please have a look and let me know what's wrong
here. I wanted to capture all steps that's why it is a large file. Let me
know if you'd like me to capture it differently.
DESKTOP-385BO5O.02-05-2016.15-39-10.zip.remove
<https://drive.google.com/file/d/0B3b1oWO5aYLWc2JLRWtJQUcxUmM/view?usp=drive_web>
Thanks,
Neetu
On Thu, Jan 21, 2016 at 3:58 PM, Matthew van Eerde <
Matthew.van.Eerde@xxxxxxxxxxxxx> wrote:
OK.
What version of Windows is this? Can you send traces?
http://blogs.msdn.com/b/matthew_van_eerde/archive/2015/08/11/taking-audio-glitch-traces-on-windows-10-desktop-edition.aspx
*From:* wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:
wdmaudiodev-bounce@xxxxxxxxxxxxx] *On Behalf Of *Paul _
*Sent:* Wednesday, January 20, 2016 10:17 PM
*To:* wdmaudiodev@xxxxxxxxxxxxx
*Subject:* [wdmaudiodev] Re: Windows 10 variable sample rate support,
WDM driver
Yes, after we send a “KSEVENT_PINCAPS_FORMATCHANGE” event, our call back
get called to tell us that the format has changed. (We are setting a
breakpoint in our event handler to check this.)
We would expect “NewStream” to be called to test what format we now
support, but this never happens.
Thanks,
Paul
