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: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> on
behalf of Eugene Muzychenko <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
the issues you're seeing now with virtual audio devices has existed
across all past releases of Windows.
Let's start by covering how Windows OS updates work for audio.
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.
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 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.
