Forwarding reply from actual audio dev, since for some reason sending directly
to the list isn’t 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).
