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

  • From: "Vincent Burel \(VB-Audio\)" <vincent.burel@xxxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Fri, 1 Feb 2019 08:44:14 +0100

You know Gary, there is only 2 kind of programmers in the world, 

 

1-      The one who spend all his time to justify his crap… You know, the
guy who coded 10 lines 10 years ago and still explaining how much it was
rational and smart… 

2-      The one who simply correct the problem.

 

Fortunately you are part of the second category , isn’t it ?. 

 

Great ! because if the next WIN10 update again fuck up audio driver
installation and/or configuration, you will hear about “large benefice for
users”.

 

BTW: I’m still losing my time in replying to several e-mail or messages
every day about the last WIN10 update who set the recording device in
minimal audio default format : 8000Hz for our driver! Thanks for that !

 

Regards

Vincent Burel

 

De : wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Gary Daniels
(Redacted sender "Gary.Daniels" for DMARC)
Envoyé : vendredi 1 février 2019 02:40
À : Matthew van Eerde
Objet : [wdmaudiodev] Re: Is there a way to force clearing device property
cache on device uninstallation?

 

Hello,

 

I understand that you are talking about uninstall and reinstall, however
please understand that your customers are going to see the same behavior
you're seeing right now for uninstall and reinstall whenever they do an OS
upgrade, and would have seen this behavior on all prior OS versions on OS
upgrade. The driver needs to be fixed to work for OS upgrades, and once the
driver is fixed the uninstall and reinstall will also start working
correctly, with the only side effect being that a small number of critical
user settings are retained even though the device was uninstalled, primarily
user default preferences, custom names and custom icons, and effect
preferences.

 

Another thing to understand is that AudioEndpointBuilder deleted endpoint
data based on the existence of the devnode, but there are transient
conditions during OS upgrade where the devnode can leave and come back. When
that happened user settings were lost, and users filed feedback. This change
is a response to the user feedback. To you uninstall and reinstall, and OS
upgrade are two different things. To AudioEndpointBuilder service, they are
intermingled.

 

I accept your feedback that you preferred the prior behavior of the settings
being deleted, but please understand that these changes were not done
lightheartedly, they were done as a direct result of many user feedbacks and
have been largely beneficial for users. I'll create a work item to see if
there's some way for AudioEndpointBuilder to identify a user initiated
driver uninstall, and delete the settings for that situation. I currently
have no way to distinguish a user initiated uninstall from system initiated
transient condition that is part of a driver update or OS upgrade.

 

Regarding the naming.

 

imagine two drivers:

ROOT\MEDIA\0001\wave1

ROOT\MEDIA\0001\wave2

ROOT\MEDIA\0002\wave1

ROOT\MEDIA\0002\wave2

 

This is the string that is used for matching the user preference for
migration. 0001 and 0002 are ignored, as those are generated instance
numbers which change across OS and (some) driver updates depending on how
the driver update package is made. You might not see these change for your
specific case, however for things like HDMI drivers they do change. wave1
for driver 1 and wave1 for driver 2 are identical from the migration
perspective and user settings will be mixed up between these two drivers for
these endpoints.

 

The correct thing to do here is to use a unique reference string that
correlates to the function of the device and is, preferably, unique enough
to not get mixed up with other manufacturers because root enumerated devices
lack a vid and pid. For example, if my driver is the "SuperVad" (r) driver,
I could do something like this:

ROOT\MEDIA\0001\SuperVadMicrophoneArrayFrontWave

ROOT\MEDIA\0001\SuperVadMicrophoneArrayRearWave

ROOT\MEDIA\0002\SuperVadLineInJackFrontWave

ROOT\MEDIA\0002\SuperVadLineInJackRearWave

 

I am not suggesting to use a GUID or some runtime generated random value for
the reference string. The reference string must be repeatable across OS
installs, but it does need to be unique for root enumerated devices like
these.

 

Regards,

Gary Daniels 

 

 

Sent from Outlook <http://aka.ms/weboutlook

  _____  

From: Gary Daniels
Sent: Thursday, January 31, 2019 5:25:10 PM
To: Matthew van Eerde
Subject: Re: [wdmaudiodev] Re: Is there a way to force clearing device
property cache on device uninstallation? 

 

Hello,

 

I understand that you are talking about uninstall and reinstall, however
please understand that your customers are going to see the same behavior
you're seeing right now for uninstall and reinstall whenever they do an OS
upgrade, and would have seen this behavior on all prior OS versions on OS
upgrade. The driver needs to be fixed to work for OS upgrades, and once the
driver is fixed the uninstall and reinstall will also start working
correctly, with the only side effect being that a small number of critical
user settings are retained even though the device was uninstalled, primarily
user default preferences, custom names and custom icons, and effect
preferences.

 

Another thing to understand is that AudioEndpointBuilder deleted endpoints
based on the existence of the devnode, but there are transient conditions
during OS upgrade where the devnode can leave and come back. When that
happened user settings were lost, and users filed feedback. This change is a
response to the user feedback. To you uninstall and reinstall, and OS
upgrade are two different things. To AudioEndpointBuilder service, they are
intermingled and have always been intermingled.

 

I accept your feedback that you preferred the prior behavior of the settings
being deleted, but please understand that these changes were not done
lightheartedly, they were done as a direct result of many user feedbacks and
have been largely beneficial for users. I'll create a work item to see if
there's some way for AudioEndpointBuilder to identify a user initiated
driver uninstall, and delete the settings for that situation. I currently
have no way to distinguish a user initiated uninstall from system initiated
done as part of a driver update or OS upgrade.

 

Regarding the naming.

 

imagine two drivers:

ROOT\MEDIA\0001\wave1

ROOT\MEDIA\0001\wave2

ROOT\MEDIA\0002\wave1

ROOT\MEDIA\0002\wave2

 

This is the string that is used for matching the user preference for
migration. 0001 and 0002 are ignored, as those are generated instance
numbers which change across OS and (some) driver updates depending on how
the driver update package is made. You might not see these change for your
specific case, however for things like HDMI drivers they do change. wave1
for driver 1 and wave2 for driver 2 are identical from the migration
perspective and user settings will be mixed up between these two drivers for
these endpoints.

 

The correct thing to do here is to use a unique reference string that
correlates to the function of the device and is, preferably, unique enough
to not get mixed up with other manufacturers because root enumerated devices
lack a vid and pid. For example, if my driver is the "SuperVad" (r) driver,
I could do something like this:

ROOT\MEDIA\0001\SuperVadMicrophoneArrayFrontWave

ROOT\MEDIA\0001\SuperVadMicrophoneArrayRearWave

ROOT\MEDIA\0002\SuperVadLineInJackFrontWave

ROOT\MEDIA\0002\SuperVadLineInJackRearWave

 

I am not suggesting to use a GUID or some non-deterministic runtime
generated value for the reference string. The reference string must be
repeatable across OS installs, but it does need to be unique for root
enumerated device like these.

 

Regards,

Gary Daniels 

 

Sent from Outlook <http://aka.ms/weboutlook

  _____  

From:  <mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
wdmaudiodev-bounce@xxxxxxxxxxxxx < <mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
wdmaudiodev-bounce@xxxxxxxxxxxxx> on behalf of Eugene Muzychenko <
<mailto:reg.wad@xxxxxxxxxxxxxx> reg.wad@xxxxxxxxxxxxxx>
Sent: Thursday, January 31, 2019 9:08:10 AM
To: Matthew van Eerde
Subject: [wdmaudiodev] Re: Is there a way to force clearing device property
cache on device uninstallation? 

 

Hello Matthew,

Forwarding reply from actual audio dev

Thank you for the forward.

======================================

the issues you're seeing now with virtual audio devices has existed
across all past releases of Windows.

They are observed in Windows 10 only. All previous 6.x systems delete
MMDevice entries as the appropriate audio device is uninstalled.

Let's start by covering how Windows OS updates work for audio.

I'm not telling about OS upgrades, just about device
installation/removal.

In this particular case, because these virtual drivers are root
enumerated, there isn't a hardware ID available.

Why are HW IDs not available? Each virtual audio driver specifies its
unique hardware ID in its INF file.

The only comparable piece of information is the reference string.

I don't know how it works with OS upgrades, but with device
installation/uninstallation, the instance ID is compared too.

If a virtual device was installed as ROOT\MEDIA\0001, and its driver
exposed KS interfaces, device endpoints are registered in MMDevice
database with the appropriate interfaces names that include device
instance name.

If then another virtual device that uses the same driver, with a
different hardware ID, is installed as ROOT\MEDIA\0002, new MMDevice
entries are created for it because there is no such instance ID in
MMDevice database.

But if both devices are uninstalled, but their MMDevice entries are not
deleted by Windows 10, and then the second device is installed as
ROOT\MEDIA\0001, there already are old entries in MMDevice with
matching interface names (instance ID + category GUID + reference
string). So Windows 10 Endpoint Builder supposes that the same device
was reinstalled, however device's hardware ID is different.

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.

I understand that retaining user audio settings after OS upgrade is
important. But what is the reason to retain such settings after device
uninstallation? If a user uninstalls a device, he either stops using
it at all, or wants to remove all traces from the system and install
it from scratch. But aggressive property caching in Windows 10 takes
away user's opportunity to perform a cleanup.

If you consider that such Windows 10 behavior is correct and
reasonable, there obviously should be a way (both programmatic and
manual) to force Endpoint Builder to delete MMDevice entries related
to the device being uninstalled.

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.

Generating unique reference strings is not a good idea because they
identify particular resources within the device. The much more
reasonable is to have unique hardware ID, and use it instead of
auto-generated instance ID, installing the device in ROOT\hwid\0000
instead of ROOT\MEDIA\nnnn.

But, anyway, MMDevice database in Windows 10 can only grow but cannot
shrink. It is not a good design, there should be a way to remove
system and/or user settings related to a particular device, even
without uninstallation of the device.

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.wdmaudi
odev.com%2F
<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.wdmaud
iodev.com%2F&amp;data=02%7C01%7CGary.Daniels%40microsoft.com%7Cb8d5b6a179d34
344383008d6879ec2c9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63684551330
3780763&amp;sdata=nLhKFly%2BMQsRFubq5hmRRixhDsVoPt6qxXZFyfyHFKY%3D&amp;reser
ved=0>
&amp;data=02%7C01%7CGary.Daniels%40microsoft.com%7Cb8d5b6a179d34344383008d68
79ec2c9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636845513303780763&amp;
sdata=nLhKFly%2BMQsRFubq5hmRRixhDsVoPt6qxXZFyfyHFKY%3D&amp;reserved=0

Other related posts: