[wdmaudiodev] Re: [EXTERNAL] Same problem with WIN10 update 2004

From: "Matthew van Eerde" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "Matthew.van.Eerde" for DMARC)
To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
Date: Mon, 15 Jun 2020 16:25:13 +0000

Have you tried adding uniquifying information into the reference string as
suggested below?

From: Vincent Burel (VB-Audio)<mailto:vincent.burel@xxxxxxxxxxxx>
Sent: Sunday, June 14, 2020 1:23 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Cc: Gary Daniels<mailto:Gary.Daniels@xxxxxxxxxxxxx>; 'Jerry
Evans'<mailto:jerry@xxxxxxxxxxx>
Subject: [EXTERNAL] [wdmaudiodev] Same problem with WIN10 update 2004

Hello,

With WIN10 2004 update, we are getting same problem again where audio device
drivers are possibly badly reinstalled as described in the thread below

Consequently, audio stack is in  such mess after WIN10 update that many users
can get many problems with audio …

Note we talk about this problem since several years now and we think it’s time
to fix it. Thanks by advance!

Regards
Vincent Burel

De : wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] ;
De la part de Vincent Burel (VB-Audio)
Envoyé : mercredi 29 janvier 2020 10:39
À : wdmaudiodev@xxxxxxxxxxxxx
Cc : 'Gary Daniels'; 'Jerry Evans'
Objet : [wdmaudiodev] Re: [EXTERNAL] Re: Typical audio problem with WIN10 update

Gary, Matthew, …

We need a response to my question of my last post, especially my last question.

95% of our user support is pending on this problem, where pin name and icon are
mixed in several independent drivers after WIN10 update.

We got a track here regarding REFERENCE STRING… I’ve seen that many
manufacturers are using the same “Wave” reference string (including Microsoft
e.g. wdma_bt.inf)

AddInterface=%KSCATEGORY_AUDIO%,"Topo",MyDriver.I.Topo
AddInterface=%KSCATEGORY_AUDIO%,"Wave", MyDriver.I.Wave

But I’ve also seen some manufacturers using GUID string instead of explicit or
generic REFERENCE STRING (wondering how they got this idea ?).

So I re-write my question:
Audio DRIVER using the same reference string (“wave”) might interact together
during WIN10 update and exchange pin name and icon ?
Is it possible ? if yes, it is a bug in Windows Audio driver installation
process, could it be corrected ASAP ?

Regards
Vincent Burel

De : wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Vincent Burel ;(VB-Audio)
Envoyé : jeudi 23 janvier 2020 08:20
À : wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Cc : 'Gary Daniels'; 'Jerry Evans'
Objet : [wdmaudiodev] Re: [EXTERNAL] Re: Typical audio problem with WIN10 update

Well, this is not clear at all.

I remind you we are talking about  audio driver having unique HardwareID and
unique ReferenceString (“Wave”) for its capture and render pins…
for a declaration like this in INF file:
AddInterface=%KSCATEGORY_AUDIO%,"Topo",MyDriver.I.Topo
AddInterface=%KSCATEGORY_AUDIO%,"Wave", MyDriver.I.Wave
AddInterface=%KSCATEGORY_CAPTURE%,"Wave", MyDriver.I.Wave
AddInterface=%KSCATEGORY_RENDER%,"Wave", MyDriver.I.Wave

And in adapter.cpp the call to InstallSubdevice in StartDevice function.
InstallSubdevice(DeviceObject, Irp, L"Topology",…
InstallSubdevice(DeviceObject, Irp, L"Wave",

FIRST QUESTION:
Is it the way it goes or not ? Do we have something to correct in these lines
above ?

SECOND QUESTION:
Our driver (and most virtual audio driver) are not made to be installed twice.
Are you suggesting that the driver can be installed twice anyway in a
installation process or WIN10 update process ?

LAST QUESTION:
The original subject is the mess in audio driver pin name and icon after win10
update. More precisely, we talk about a mess between different drivers
(possible from different manufacturers): That a driver A could take the pin
name of a Driver B after a Windows 10 update. Are you trying to explain this
problem , or are you talking about something else ?

Regards
Vincent Burel

De : Gary Daniels [mailto:Gary.Daniels@xxxxxxxxxxxxx]
Envoyé : mercredi 22 janvier 2020 22:46
À : Jerry Evans; wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>;
'Vincent Burel (VB-Audio)'
Objet : Re: [wdmaudiodev] Re: [EXTERNAL] Re: Typical audio problem with WIN10
update

To be clear, the string "sysvad_tabletaudiosample" originates from the inf
file. The full string I provided is an example of a PNP interface path, which
is defined by PNP, not the driver.

So, to be utterly clear. If you have a software audio driver and give it an id
of "novadsp.com" inside of the inf and you only ever have to install this
driver in a system a single time, then it will work for upgrades.

If this driver is installed more than once, say for two different instances of
a virtual patch cable, it will break.

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

From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> on
behalf of Jerry Evans <jerry@xxxxxxxxxxx<mailto:jerry@xxxxxxxxxxx>>
Sent: Wednesday, January 22, 2020 11:32 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
<wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>>; 'Vincent Burel
(VB-Audio)' <vincent.burel@xxxxxxxxxxxx<mailto:vincent.burel@xxxxxxxxxxxx>>
Subject: [wdmaudiodev] Re: [EXTERNAL] Re: Typical audio problem with WIN10
update

Hi Gary

I’m not actually shipping any sysvad drivers but just to be utterly clear here 😊

Using your example:

\\?\root#sysvad_tabletaudiosample#0001#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\wavespdif<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Foutlook.office.com%2F%3F%255Chdaudio%23func_01%26ven_1002%26dev_aa01%26subsys_00aa0100%26rev_1007%235%261ccdf6ec%260%260001%23%257B6994ad04-93ef-11d0-a3cc-00a0c9223196%257D%255Ce1hdmiouttopo&data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7Cbb6fc236101343c5d66808d8103c430e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637277198363016217&sdata=rMHhjbl8Sm1PzfhnTLbvgLwUDbanl9YCsvguRYEro8s%3D&reserved=0>

To avoid the collision you describe, and given a TLD I know to be unique, I’d
need to define the path string in the following way?

\\?\root#novadsp.com#0001#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\wavespdif<file://%3f/root%23novadsp.com%230001%23%7b6994ad04-93ef-11d0-a3cc-00a0c9223196%7d/wavespdif>

MTIA.

Jerry

From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> On
Behalf Of Gary Daniels (Redacted sender "Gary.Daniels" for DMARC)
Sent: 22 January 2020 18:20
To: Vincent Burel (VB-Audio)
<vincent.burel@xxxxxxxxxxxx<mailto:vincent.burel@xxxxxxxxxxxx>>;
wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] Re: [EXTERNAL] Re: Typical audio problem with WIN10
update

The string needs to be unique for all instance of a driver with the same
hardware id.

Lets say you install the sysvad driver twice in a system as a root enumerated
software driver without a unique hardware id. Before an OS upgrade you give
each sysvad endpoint on these two drivers some user customizations. After the
upgrade you'll still see two instances of the driver installed, but the audio
settings will be jumbled.

If you take the sample code and create a software driver using the generic wave
and topology names provided in the sample and don't change it, and some other
developer does the same, and they're both root enumerated software drivers,
then the settings between those two driver will get jumbled on upgrade.

Going back to the string I showed below:

\\?\root#sysvad_tabletaudiosample#0001#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\wavespdif<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Foutlook.office.com%2F%3F%255Chdaudio%23func_01%26ven_1002%26dev_aa01%26subsys_00aa0100%26rev_1007%235%261ccdf6ec%260%260001%23%257B6994ad04-93ef-11d0-a3cc-00a0c9223196%257D%255Ce1hdmiouttopo&data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7Cbb6fc236101343c5d66808d8103c430e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637277198363016217&sdata=rMHhjbl8Sm1PzfhnTLbvgLwUDbanl9YCsvguRYEro8s%3D&reserved=0>

The piece between the first and second hash marks is part of the comparison,
the piece between the second and third is not. Depending on how you author the
inf and do the driver install I have seen instances where the portion between
the first and second hash is empty, it's simply
"\\?\root##0001#...<file://%3f/root%23%230001%23...>".

If you carefully author your inf's and install the driver so that the string
between the first and second hash marks is unique and you only use it once,
then that will also work, you can reuse the reference string. If you're
installing your driver more than once and the piece between the first and
second hash is not unique or missing entirely, then the reference string must
be unique.

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

From: Vincent Burel (VB-Audio)
<vincent.burel@xxxxxxxxxxxx<mailto:vincent.burel@xxxxxxxxxxxx>>
Sent: Wednesday, January 22, 2020 6:42 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
<wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>>
Cc: Gary Daniels <Gary.Daniels@xxxxxxxxxxxxx<mailto:Gary.Daniels@xxxxxxxxxxxxx>>
Subject: RE: [wdmaudiodev] Re: [EXTERNAL] Re: Typical audio problem with WIN10
update

Gary, to be sure about what you say :

You are explaining that %KSNAME_WaveSpeaker% and %KSNAME_TopologySpeaker%

Must be unique Reference String, regarding all drivers in the world ? to avoid
the re-installation problem we are talking about

Meaning that potentially all drivers using the same

KSNAME_WaveSpeaker = « Wave »

KSNAME_TopologySpeaker = « Topology »

Could interact together and create problem during any installation process ?

This is what you are saying ?

Regards

Vincent Burel

De : wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Gary Daniels ;(Redacted
sender "Gary.Daniels" for DMARC)
Envoyé : mardi 21 janvier 2020 23:41
À : Vincent Burel (VB-Audio);
wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Objet : [wdmaudiodev] Re: [EXTERNAL] Re: Typical audio problem with WIN10 update

Now I understand where the miscommunication is about reference string.

From the sample inf:

AddInterface=%KSCATEGORY_AUDIO%, %KSNAME_WaveSpeaker%, SYSVAD.I.WaveSpeaker

AddInterface=%KSCATEGORY_RENDER%, %KSNAME_WaveSpeaker%, SYSVAD.I.WaveSpeaker

AddInterface=%KSCATEGORY_REALTIME%, %KSNAME_WaveSpeaker%, SYSVAD.I.WaveSpeaker

AddInterface=%KSCATEGORY_AUDIO%, %KSNAME_TopologySpeaker%,
SYSVAD.I.TopologySpeaker

AddInterface=%KSCATEGORY_TOPOLOGY%, %KSNAME_TopologySpeaker%,
SYSVAD.I.TopologySpeaker

%KSNAME_WaveSpeaker% and %KSNAME_TopologySpeaker% are the reference strings for
these interfaces.

These strings have to match the interfaces that are registered with pnp from
the driver. In the sysvad sample the string used with PNP to register the
interface is in the ENDPOINT_MINIPAIR. So, changing in just the inf or just in
the driver is not enough, they need to be changed in both and need to match.

If you take a look in the mmdevice registry store for sysvad, you'll see
something like this data value for one of the property keys. This is the device
interface path. In this case wavespdif is the reference string.

\\?\root#sysvad_tabletaudiosample#0001#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\wavespdif<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Foutlook.office.com%2F%3F%255Chdaudio%23func_01%26ven_1002%26dev_aa01%26subsys_00aa0100%26rev_1007%235%261ccdf6ec%260%260001%23%257B6994ad04-93ef-11d0-a3cc-00a0c9223196%257D%255Ce1hdmiouttopo&data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7Cbb6fc236101343c5d66808d8103c430e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637277198363026213&sdata=hhgascD0ruylzD5ql4EXvkm4dO7E4tNKPs3KupP3JXs%3D&reserved=0>

On a system exhibiting the upgrade problems, go through all of your audio
endpoints in mmdevices\audio\ and grab a copy of the interface path w/
reference string, I expect that you'll find that the strings are practically
identical across all of the endpoints getting jumbled.

The portion of the string between the 2nd and 3rd hash marks is ignored, as it
can change across OS upgrades. This means that from an OS upgrade perspective:

\\?\root#sysvad_tabletaudiosample#0001#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\wavespdif<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Foutlook.office.com%2F%3F%255Chdaudio%23func_01%26ven_1002%26dev_aa01%26subsys_00aa0100%26rev_1007%235%261ccdf6ec%260%260001%23%257B6994ad04-93ef-11d0-a3cc-00a0c9223196%257D%255Ce1hdmiouttopo&data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7Cbb6fc236101343c5d66808d8103c430e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637277198363036207&sdata=sMlp4dlcPzNngHT6Ma9pIdhhwOgjs%2BNdC%2FSanJ6jW4s%3D&reserved=0>
==
\\?\root#sysvad_tabletaudiosample#0002#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\wavespdif<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Foutlook.office.com%2F%3F%255Chdaudio%23func_01%26ven_1002%26dev_aa01%26subsys_00aa0100%26rev_1007%235%261ccdf6ec%260%260001%23%257B6994ad04-93ef-11d0-a3cc-00a0c9223196%257D%255Ce1hdmiouttopo&data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7Cbb6fc236101343c5d66808d8103c430e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637277198363036207&sdata=sMlp4dlcPzNngHT6Ma9pIdhhwOgjs%2BNdC%2FSanJ6jW4s%3D&reserved=0>

It's this ignored portion between the 2nd and 3rd hash marks which can change
during upgrade that causes issues with upgrading software devices when there
are multiple instances of the driver installed. With multiple instances of the
same software driver, the contents between the 2nd and 3rd hash marks is the
only part that is different.

I don't know if the following will be useful or not. If you take a look at the
Bluetooth sideband implementation in sysvad, you'll see something special
there. The INF and the endpoint_minipairs don't line up. In the endpoint
minipair structure the reference string is NULL. Instead there is different
value, a reference string template entry with a name like BTHHFP_MIC_TOPO_NAME.
The inf adds an interface named  BTHHFP_MIC_TOPO_NAME, but that interface isn't
ever activated, it's used as a template. Instead, Bluetooth sideband uses a
runtime generated string for the reference string. We need a runtime generated
string to ensure that every paired Bluetooth peripheral retains its own
settings for format, name, etc. The string we use is the mac address for the
Bluetooth peripheral that is paired. It's repeatable and unique to the
peripheral. At activation time, the registry keys added via inf for
BTHHFP_MIC_TOPO_NAME are copied over. This way you can register APO's and set
endpoint property keys in the INF, before the reference strings are known and
they get copied to the right locations at runtime. This is one example of a way
to do a unique reference string chosen at runtime.

For your other statement about windows updates not creating a new driver.
Windows update has always installed the drivers new for upgrade. Back in the
Win 9x days (before my time) I've been told that the PNP system didn't have a
concept of migrating down-level os settings. It installed everything fresh for
an OS upgrade and then the multimedia class installer, a multimedia component,
not PNP, performed the migration of audio driver settings from the old drivers
to the new drivers. If the networking team wanted to migrate driver settings,
then they would have had to create their own component to migrate their PNP
settings for their drivers. Nowadays PNP still installs new, and then performs
a migration for all the drivers. So, originally the audio stack migrated
everything, PNP and audio settings. Then sometime in the win7 days (also before
me) PNP created a standard migration solution and the process split into two,
with PNP performing its part and the audio stack performing its part. The key
piece here is that even back in the 9x days the driver was a new install after
upgrade, which broke the connection from the device interfaces to the audio
interfaces. So, mmci back then used the same logic that is still used today to
match the pre-upgrade data to the post-upgrade driver and perform the
migration. It may not look like it's a new install to the driver, but it is.
Read through the setupapi logs, you'll see that it copies forward the driver
store, performs an install, and then migrates settings from old to new.

Eugene, You are correct, changing the reference string is not a valid
workaround for format issues. Back in the original mail last year I
specifically called out that it is not OK to tie the reference string to the
format. The reference string needs to be static because changing it breaks the
users default endpoint selections, loses their customizations, etc. Changing
the reference string only makes sense if it's a different audio endpoint, like
the Bluetooth example above. I'd recommend filing a feedback with a repro of
any situations you find where firing the KSEVENT_PINCAPS_FORMATCHANGE event
didn't work as expected. Include your expectations and what you actually saw
happen. If you send me the link to the feedback (gary.daniels at Microsoft),
I'll forward it to the owners of audiosrv.

Hope that helps,

-Gary

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

From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> on
behalf of Vincent Burel (VB-Audio)
<vincent.burel@xxxxxxxxxxxx<mailto:vincent.burel@xxxxxxxxxxxx>>
Sent: Sunday, January 19, 2020 11:38 PM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
<wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>>
Subject: [wdmaudiodev] Re: [EXTERNAL] Re: Typical audio problem with WIN10
update

Hello Gary,

Just to repeat my question with more precisions:

In the INF file, all the following strings are unique and different for all our
virtual audio drivers

DeviceName

HardwareId

ServiceName

DriverFile

INPUTGUID

OUTPUTGUID

NAMELine1

INPUTNAME

OUTPUTNAME

In Source files, all GUID are also unique and different for all our virtual
audio drivers

// interface GUID

                //Friendly name line-in

                //Friendly name line-out

So, what REFERENCE STRING are you talking about ?

Regards

Vincent Burel

De : wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Vincent Burel ;(VB-Audio)
Envoyé : vendredi 17 janvier 2020 21:04
À : wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Objet : [wdmaudiodev] Re: [EXTERNAL] Re: Typical audio problem with WIN10 update

Hello,

Thanks to come back to this, but

1-      Before WIN10 there was no automatic update with audio driver
re-installation.

2-      All our hardware ID are unique for each driver of course… so what
reference string are you talking about exactly ? where it is supposed to be in
the source code ? in the inf file ? what are you talking about ?

Also the problem does not affect our audio driver only, the pin and icon name
confusing can happen with other audio drivers as well…

You may check this problem with more attention, because I don’t think it’s
exclusively driver related…

Regards

Vincent Burel

De : 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 17 janvier 2020 19:31
À : Matthew van Eerde;
wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Objet : [wdmaudiodev] Re: [EXTERNAL] Re: Typical audio problem with WIN10 update

Hi Vincent,

Please refer back to the instructions given to you in the 1/31/19 thread.

At the time your complaint was that the audio endpoint settings were being
mixed up after uninstall and reinstall. I broke this complaint into two pieces,
settings not being removed and settings getting mixed up.

I explained at the time that the change to retain the settings upon uninstall
was intended to make the system behave more consistently by making uninstall
and reinstall behave the same as upgrade, and also to fix customer issues with
lost settings during upgrade. After that discussion, I was able to find a way
to solve the issue with lost user settings on upgrade while also retaining the
manual uninstallation behavior which you and others had come to expect, so the
current release of windows removes user settings when the audio driver is
uninstalled.

As I said at the time: "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."

So, now your complaint is that you're seeing the settings mix up on OS upgrades
and it happens on all of the versions of Windows you've checked, exactly as I
said last year. The issue you are seeing with upgrades is by design, it is how
the OS upgrade system works, how it has always worked, and will not be
changing. Now that I've changed driver uninstall to remove the settings, as
requested, you're going to have a much more difficult time validating your
driver fix to handle OS upgrades because OS upgrades and driver uninstall and
reinstall once again behave differently.

I directed you to solving the settings mix up by using unique reference
strings. I provided lots of explanation on how upgrades work why this is
necessary, summarized here:

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

Nothing has changed or will change with this. The OS upgrade process breaks the
connection between the PNP interfaces and the audio settings. The audio system
then has to reconnect the audio settings to the PNP interfaces after the
upgrade completes, bringing the user settings from an old OS to a newly
installed OS with a newly installed driver. It does this by matching hardware
id and reference string. Your interfaces do not have unique hardware id's or
unique reference strings, so the settings cannot be accurately matched.

Thanks,

Gary Daniels

Senior SDE, Windows Audio

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

From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> on
behalf of Matthew van Eerde
<dmarc-noreply@xxxxxxxxxxxxx<mailto:dmarc-noreply@xxxxxxxxxxxxx>>
Sent: Monday, January 6, 2020 8:24 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
<wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>>
Subject: [wdmaudiodev] Re: [EXTERNAL] Re: Typical audio problem with WIN10
update

Happy new year to you as well :-)

From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> on
behalf of Vincent Burel (VB-Audio)
<vincent.burel@xxxxxxxxxxxx<mailto:vincent.burel@xxxxxxxxxxxx>>
Sent: Saturday, January 4, 2020 2:48:45 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
<wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>>
Subject: [wdmaudiodev] Re: [EXTERNAL] Re: Typical audio problem with WIN10
update

If you were still not aware about WIN10 update problem, there is a clear
article there:

https://www.forbes.com/sites/gordonkelly/2020/01/02/microsoft-windows-10-warning-file-explorer-crash-search-upgrade-windows-10/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.forbes.com%2Fsites%2Fgordonkelly%2F2020%2F01%2F02%2Fmicrosoft-windows-10-warning-file-explorer-crash-search-upgrade-windows-10%2F&data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7Cbb6fc236101343c5d66808d8103c430e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637277198363046206&sdata=ESgSQlv9nK4EsmeHibQn8v18U2%2FSXMetvJ1TvfcKdOg%3D&reserved=0>

apparently the issue is not limited to audio driver, but all core components !

Happy new year by the way!

Regards

Vincent Burel

De : wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Vincent Burel ;(VB-Audio)
Envoyé : vendredi 3 janvier 2020 18:31
À : wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Objet : [wdmaudiodev] Re: [EXTERNAL] Re: Typical audio problem with WIN10 update

Regarding this problem: WIN10 update and bad audio driver re-installation.

No progress has been made since years, maybe since VISTA,

that’s why most of music and video production stayed on MAC.

So you are right! Fixing this audio device management bug is not guarantee!

And any log won’t change anything if you do not want to correct this issue…

Regards

Vincent Burel

De : wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Matthew van Eerde ;
(Redacted sender "Matthew.van.Eerde" for DMARC)
Envoyé : vendredi 3 janvier 2020 17:18
À : wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Objet : [wdmaudiodev] Re: [EXTERNAL] Re: Typical audio problem with WIN10 update

If you’re unwilling to provide logs it is unlikely any progress will be made.

(Even if you provide logs, there is no guarantee.)

From: Vincent Burel (VB-Audio)<mailto:vincent.burel@xxxxxxxxxxxx>
Sent: Friday, January 3, 2020 2:10 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] Re: [EXTERNAL] Re: Typical audio problem with WIN10
update

No, sorry, this is something you should be aware about.

This is a very common issue (search for audio problem after win10 update on
google… )

You can also reproduce it by yourself…

Install voicemeeter Banana and VB-CABLE… REBOOT and use it for test…

Then reconnect to internet to get the WIN10 update…

And you will see the mess in audio driver after reboot.

Also Gary Daniels already told you about this problem in a message there in
February 2019

“Re: Is there a way to force clearing device property cache on device
uninstallation?”

I thought Microsoft would correct this and consequences as well!

Regards

Vincent Burel

De : wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Matthew van Eerde ;
(Redacted sender "Matthew.van.Eerde" for DMARC)
Envoyé : jeudi 2 janvier 2020 19:52
À : wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Objet : [wdmaudiodev] Re: [EXTERNAL] Re: Typical audio problem with WIN10 update

Can you file a problem report in Feedback Hub, from a system in the problem
state, and share a link?

From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> on
behalf of Vincent Burel (VB-Audio)
<vincent.burel@xxxxxxxxxxxx<mailto:vincent.burel@xxxxxxxxxxxx>>
Sent: Monday, December 30, 2019 12:42:08 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
<wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>>
Subject: [EXTERNAL] [wdmaudiodev] Re: Typical audio problem with WIN10 update

For Matthew, and other experts at Microsoft…

We have another simple explanation of the WIN10 update problem and audio driver:

https://forum.vb-audio.com/viewtopic.php?f=7&t=688<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforum.vb-audio.com%2Fviewtopic.php%3Ff%3D7%26t%3D688&data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7Cbb6fc236101343c5d66808d8103c430e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637277198363046206&sdata=cPDNKtuvKHUIF3D%2FT45wtBtVDa6L8Xy3ZNGPO3C2xAw%3D&reserved=0>

On the topic above, the second message includes an image showing how our audio
devices are present in Windows Sound Dialog box after a good installation.

After a WIN10 update, icon and pin name (bold name of the device) can be
exchanged between drivers.

For example we can have the VB-CABLE A with the icon and the pin name of the
Voicemeeter AUX driver…

Then nothing works correct, audio device selection is corrupted in all
applications of course, and audio is not working correct.

And this is done from a day to another with automatic WIN10 update…

The only solution we have is to ask users to de-install all VB-CABLEs and
Voicemeeter… and re-install them.

(the fact is that it does not happen only to our drivers and can disturb the
audio stack for ever if the corrupted audio driver is not re-installed) .

Could you fix this problem ? present on WIN10 since the beginning…

And possibly on WIN7, or even VISTA too… but there is less automatic update
with audio driver re-installation…

Regards

Vincent Burel

De : wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Vincent Burel ;(VB-Audio)
Envoyé : vendredi 22 novembre 2019 08:25
À : wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Objet : [wdmaudiodev] Typical audio problem with WIN10 update

Matthew, and others at Microsoft…

As typical case, we have a nice thread on our forum that could help you to see
the problem we are talking about:

https://forum.vb-audio.com/viewtopic.php?f=6&t=886<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforum.vb-audio.com%2Fviewtopic.php%3Ff%3D6%26t%3D886&data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7Cbb6fc236101343c5d66808d8103c430e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637277198363056197&sdata=w4jAtQJkP1N%2FesyQHbCjqbK2GFY4yCUwX%2Ft0i65SwrM%3D&reserved=0>

where it is explained that audio can suddenly stop working after a Win10 update.

-          Audio Driver can be badly reinstalled – requiring to re-install them
again…

-          Windows Audio settings can be changed (default audio device, device
format, volume mixer…).

-          Privacy Settings regarding Microphone can also be changed (this was
the case for this problem report)…

That you have to understand is that from a day to another, a working audio
configuration is turned into a hell for users.

And for us, because we get messages/report every day on this problem…

Regards

Vincent Burel

www.voicemeeter.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.voicemeeter.com&data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7Cbb6fc236101343c5d66808d8103c430e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637277198363056197&sdata=peO8kox1RE5u2AmcM%2FprCtHgGGuBn%2BZozzQlVOvjIR0%3D&reserved=0>

De : wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Matthew van Eerde ;
(Redacted sender "Matthew.van.Eerde" for DMARC)
Envoyé : vendredi 20 septembre 2019 19:42
À : wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Objet : [wdmaudiodev] Re: The link between Audio Properties and the Driver
Endpoint.

Sorry, I’m not seeing it.

From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> on
behalf of Vincent Burel (VB-Audio)
<vincent.burel@xxxxxxxxxxxx<mailto:vincent.burel@xxxxxxxxxxxx>>
Sent: Friday, September 20, 2019 10:38:31 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
<wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>>
Subject: [wdmaudiodev] Re: The link between Audio Properties and the Driver
Endpoint.

This is a single problem, but several symptoms…

… that should place you on the track to fix it…

De : wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Matthew van Eerde ;
(Redacted sender "Matthew.van.Eerde" for DMARC)
Envoyé : vendredi 20 septembre 2019 17:32
À : wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Objet : [wdmaudiodev] Re: The link between Audio Properties and the Driver
Endpoint.

One problem at a time please.

From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> on
behalf of Vincent Burel (VB-Audio)
<vincent.burel@xxxxxxxxxxxx<mailto:vincent.burel@xxxxxxxxxxxx>>
Sent: Thursday, September 19, 2019 10:57:30 PM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
<wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>>
Subject: [wdmaudiodev] Re: The link between Audio Properties and the Driver
Endpoint.

Matthew, no kidding!

Maybe you don’t remember, but you already read or reply to several messages on
the subject:

10 AUG 2015: WIN10 update changes drivers name and icon

23 JUL 2019: SYSVAD & Certification Process Failures...

(several message explaining how all different driver installation procedures
are not working correct with SYSVAD)

13 OCT 2018: Re: virtual audio driver removed via devcon, but it's only hidden

19 JAN 2019: Re: Is there a way to force clearing device property cache on
device uninstallation?

“After installation the driver presents pin name of another driver (already
installed, or previously de-installed)”.

You will find in these messages some points from Gary Daniels explaining that
there is different potential bugs with AudioEndpointBuilder and PNP Migration
process and that also the driver must be fixed to work for OS upgrades… so you
can’t ignore the problem.

14 MAR 2019: Re: DTM audio glitch test failing

“It seems the driver installation (update) procedure is bugged and the driver
behavior can be impacted (if bad installed – mess in audio points - ).”

As you see, If you really wanted to help, it would be fixed since years.

Regards

Vincent Burel

De : wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Matthew van Eerde ;
(Redacted sender "Matthew.van.Eerde" for DMARC)
Envoyé : jeudi 19 septembre 2019 18:42
À : wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Objet : [wdmaudiodev] Re: The link between Audio Properties and the Driver
Endpoint.

  *   I definitely think that the problem is mainly located in the driver
installation process and the Audio Endpoint Point initial installation /
configuration

Tell me more. What leads you to that conclusion?

  *   Just make a google search

I want to help YOU. What problems are YOU running into?

From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> on
behalf of Vincent Burel (VB-Audio)
<vincent.burel@xxxxxxxxxxxx<mailto:vincent.burel@xxxxxxxxxxxx>>
Sent: Thursday, September 19, 2019 9:37:49 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
<wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>>
Subject: [wdmaudiodev] Re: The link between Audio Properties and the Driver
Endpoint.

I definitely think that the problem is mainly located in the driver
installation process and the Audio End Point initial installation /
configuration.

If you are interested in this, just make a google search on “WIN10 update and
audio issues” for example… you will find something every day!

Regards

Vincent Burel

De : wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Matthew van Eerde ;
(Redacted sender "Matthew.van.Eerde" for DMARC)
Envoyé : jeudi 19 septembre 2019 17:30
À : wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Objet : [wdmaudiodev] Re: The link between Audio Properties and the Driver
Endpoint.

  *   typically stuttering / discontinued audio / cut in the sound on a capture
or render stream

This has nothing to do with Dave’s question, but I’m interested anyway.

Out of respect for Dave, please start a new email thread with a new subject.

Follow the instructions here to grab logs of the problem in action:

https://matthewvaneerde.wordpress.com/2016/09/26/report-problems-with-logs-and-suggest-features-with-the-feedback-hub/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmatthewvaneerde.wordpress.com%2F2016%2F09%2F26%2Freport-problems-with-logs-and-suggest-features-with-the-feedback-hub%2F&data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7Cbb6fc236101343c5d66808d8103c430e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637277198363066191&sdata=6Rl2enz4Q6cSzjmT3pAF%2BSpt%2FDCkawUUv14QTwDLkvA%3D&reserved=0>

Grab a link to the problem report and include it in the email.

I’ll take a look at the logs and see if I can figure out what is causing the
stuttering / discontinued audio / cut in the sound.

From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> on
behalf of Vincent Burel (VB-Audio)
<vincent.burel@xxxxxxxxxxxx<mailto:vincent.burel@xxxxxxxxxxxx>>
Sent: Thursday, September 19, 2019 7:00:01 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
<wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>>
Subject: [wdmaudiodev] Re: The link between Audio Properties and the Driver
Endpoint.

Yes, precise, but complicated, and does not help us to sale and support audio
app at the end.

Today with WIN10 ( 2019):

for each update or for each new USB audio device plugged, or for each new audio
driver installation,

there is a risk for the user to get a problem somewhere in the audio stack –
typically stuttering / discontinued audio / cut in the sound on a capture or
render stream.

Example: I newly plug a USB microphone on a WIN10 computer, and then try to use
it with WASAPI or MME… no way to get  stable stream.

then I newly plug it into another WIN10 computer, use in the same way without
any problem …

Other example: I newly plug a USB device (e.g. SoundBlaster), it works ok
during the day… the day after: no way to make it work stable after computer
startup… then I reboot and it work again correct…

Audio users are simply becoming crazy with this kind of behavior….

Then I ask for questions:  Is there a way to know if the audio stack is running
correct ?  Is there a way to check that audio driver installation is correct ?
Could we have such kind diagnostic tool ?

Regards

Vincent Burel

Follow-Ups:
- [wdmaudiodev] Re: [EXTERNAL] Same problem with WIN10 update 2004
  - From: Eugene Muzychenko
- [wdmaudiodev] Re: [EXTERNAL] Same problem with WIN10 update 2004
  - From: Vincent Burel (VB-Audio)

References:
- [wdmaudiodev] Same problem with WIN10 update 2004
  - From: Vincent Burel (VB-Audio)

[wdmaudiodev] Re: [EXTERNAL] Same problem with WIN10 update 2004

Other related posts: