I must add we have more and more to cope to the situation where the driver
is not correctly installed or de-installed and any driver update or
re-installation may generate a growing mess in the audio stack
So we are
obliged to explained to users how to de-install drivers manually. see our
topic there: https://forum.vb-audio.com/viewtopic.php?f=7
<https://forum.vb-audio.com/viewtopic.php?f=7&t=688> &t=688
BTW1: The driver is already identifiable by a unique GUID or/and HardwareID
(why this is not used for the installation process ?)
BTW2 : I already told about that to Matthew: the HLK processing does not
generate the same number of error if done on the SYSVAD firstly installed
(on fresh installed windows), or on second installation (SYSVAD update ,
with new version/date).
BTW3: We are in 2019 and still talking about How to install or de-install
audio driver under Windows correctly
De : wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Vincent Burel
(VB-Audio)
Envoyé : vendredi 1 février 2019 08:44
À : wdmaudiodev@xxxxxxxxxxxxx
Objet : [wdmaudiodev] Re: Is there a way to force clearing device property
cache on device uninstallation?
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 , isnt 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: Im 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 : <mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
wdmaudiodev-bounce@xxxxxxxxxxxxx [ <mailto: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 <http://aka.ms/weboutlook> Outlook
_____
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 <http://aka.ms/weboutlook> Outlook
_____
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
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.
