[wdmaudiodev] Re: Is there a way to force clearing device property cache on device uninstallation?

  • From: "Matthew van Eerde" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "Matthew.van.Eerde" for DMARC)
  • To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Fri, 25 Jan 2019 23:34:22 +0000

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).

Most probably, such problem is linked to device instance ID (ENUM\...), not
a hardware ID, because hardware ID is not a part of the interface path.

Regards,
Eugene

******************

WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe:  mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx

URL to WDMAUDIODEV page:
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.wdmaudiodev.com%2F&amp;data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7C4ac7b0438e78484d5a7a08d67f77b37f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636836549458857590&amp;sdata=VOTbybTquDVfY2viKzzZ86RfsbM6LO4r9bixR9nU3AA%3D&amp;reserved=0

******************

WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe:  mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx

URL to WDMAUDIODEV page:
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.wdmaudiodev.com%2F&amp;data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7C4ac7b0438e78484d5a7a08d67f77b37f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636836549458857590&amp;sdata=VOTbybTquDVfY2viKzzZ86RfsbM6LO4r9bixR9nU3AA%3D&amp;reserved=0

Other related posts: