Nice to see that someone worked on this problem.
Will see if the things go better
You may also think to check (or make check) the HLK certification on a primo
installation (first driver installation on fresh windows installation) and
on a driver update (can be the same with another version/date) it does not
produce the same error number when performing the HLK certification...
Regards
Vincent Burel
De : wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Matthew van Eerde
(Redacted sender "Matthew.van.Eerde" for DMARC)
Envoyé : samedi 26 janvier 2019 00:34
À : wdmaudiodev@xxxxxxxxxxxxx
Objet : [wdmaudiodev] Re: Is there a way to force clearing device property
cache on device uninstallation?
Forwarding reply from actual audio dev, since for some reason sending
directly to the list isnt working for him:
Microsoft audio dev here, I'm responsible for most of the recent changes to
AudioEndpointBuilder and the MMDevapi system that you're seeing. I think I
can clear up all of the confusion here as to what's going on, and the
reasons for the changes that are causing you problems.
First off, let me say, the issues you're seeing now with virtual audio
devices has existed across all past releases of Windows. It was simply less
reproducible and that inconsistency resulted in user, and developer,
frustration.
Let's start by covering how Windows OS updates work for audio. When the new
Windows OS installs, the PNP system brings forward (migrates) all of the
audio drivers and their PNP settings to the newly installed OS. The audio
system then needs to match the audio property store to the migrated PNP
audio driver in order to migrate the audio user settings. This matching
ignores the driver instance information, because that changes when the
driver is migrated or updated. So, by design, the hardware id and reference
strings are the only pieces involved with this comparison. This is true for
Windows update across all versions of Windows going back to Windows 7 and
likely earlier. In this particular case, because these virtual drivers are
root enumerated, there isn't a hardware ID available. The only comparable
piece of information is the reference string.
With Windows 10, OS upgrades are much more common and has necessitated
addressing issues that have always plagued OS upgrades, but were missed in
the past due to the infrequency of it. I have investigated and root caused
many bugs from users about lost settings and broken audio after an OS
upgrade. As a result, we've made a number of changes to improve consistency,
reliability, and user experience. The OS is much more persistent about
retaining user settings now and much more consistent about when to apply the
retained user settings.
The end result is that for audio drivers the OS now behaves identically for
driver uninstall and reinstall, driver update, and OS upgrades. The same
audio user setting migration happens, the exact same way, for all three
scenarios. For driver developers, this means that once you get one of those
three scenarios working, all will work.
Only the user settings are migrated, these include things like format
preferences, APO settings, endpoint names (which can be customized by the
user), and user default selection preferences. If it can be changed in the
sound control panel it will be migrated. Generated properties, like format
capabilities, mode capabilities, form factor, and jack detection, are not
migrated. They are recreated to match the newly installed driver because
they may have changed with the new driver. If your driver stores custom
properties in the audio endpoint or audio FX property store, those won't be
migrated. However, audio settings stored on the PNP interface, if you're
familiar with using PKEY_AudioEndpoint_Association, will be brought forward.
In this particular case, because of the lack of a hardware id and reference
string reuse, the OS migration process will simply copy the settings for
every endpoint with the same reference string into a single endpoint with
the GUID that is enumerated first alphabetically. It would have done this
for all prior versions of Windows for OS upgrades, and for Windwos 10 it
does this for driver updates and reinstalls as well.
The fix should be obvious now. For root enumerated software devices, because
it lacks a hardware ID, the OS has a limitation that reference strings must
be unique to ensure that settings aren't mixed up on OS upgrades and driver
updates. Thankfully, these sorts of bugs are now much more detectable and
once you make the changes to the driver to use a unique reference string for
each endpoint (which does not change across driver uninstall and reinstall),
it will be very easy for you to validate that OS upgrades and driver updates
will all work as expected.
Gary Daniels
Senior SDE Windows Audio
_____
From: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> on
behalf of Vincent Burel (VB-Audio) <vincent.burel@xxxxxxxxxxxx>
Sent: Monday, January 21, 2019 12:08:25 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: Is there a way to force clearing device property
cache on device uninstallation?
Possible.
VB
-----Message d'origine-----
De : wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Eugene Muzychenko
Envoyé : dimanche 20 janvier 2019 15:07
À : Vincent Burel (VB-Audio)
Objet : [wdmaudiodev] Re: Is there a way to force clearing device property
cache on device uninstallation?
Hello Vincent,
After installation the driver presents pin name of another driver
(already installed, or previously de-installed).
