[wdmaudiodev] Re: [EXTERNAL] Re: Typical audio problem with WIN10 update

  • From: "Gary Daniels" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "Gary.Daniels" for DMARC)
  • To: "Vincent Burel (VB-Audio)" <vincent.burel@xxxxxxxxxxxx>, "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Tue, 21 Jan 2020 22:41:16 +0000

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://outlook.office.com//?\hdaudio#func_01&ven_1002&dev_aa01&subsys_00aa0100&rev_1007#5&1ccdf6ec&0&0001#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\e1hdmiouttopo>

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://outlook.office.com//?\hdaudio#func_01&ven_1002&dev_aa01&subsys_00aa0100&rev_1007#5&1ccdf6ec&0&0001#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\e1hdmiouttopo>
 == 
\\?\root#sysvad_tabletaudiosample#0002#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\wavespdif<https://outlook.office.com//?\hdaudio#func_01&ven_1002&dev_aa01&subsys_00aa0100&rev_1007#5&1ccdf6ec&0&0001#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\e1hdmiouttopo>

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 <wdmaudiodev-bounce@xxxxxxxxxxxxx> on 
behalf of Vincent Burel (VB-Audio) <vincent.burel@xxxxxxxxxxxx>
Sent: Sunday, January 19, 2020 11:38 PM
To: wdmaudiodev@xxxxxxxxxxxxx <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] ;
De la part de Vincent Burel (VB-Audio)
Envoyé : vendredi 17 janvier 2020 21:04
À : 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%7CGary.Daniels%40microsoft.com%7C5987263ed2fb41f5bb1608d792c50c62%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139247338591970&sdata=5cWThZCtNAjg5lzBI%2FHaCLdhOOGr6qzoVjSjomvnQ68%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%7CGary.Daniels%40microsoft.com%7C5987263ed2fb41f5bb1608d792c50c62%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139247338601963&sdata=pcdEM6VI5qlG6sTCE%2BawzCqrhyiqAwmEYgQL%2BeN4XoA%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%7CGary.Daniels%40microsoft.com%7C5987263ed2fb41f5bb1608d792c50c62%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139247338601963&sdata=81ZhQij1k7J0IMKwdoMAfvkU2urDVz1Uiz072MEjRrs%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%7CGary.Daniels%40microsoft.com%7C5987263ed2fb41f5bb1608d792c50c62%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139247338611958&sdata=xD%2FS%2BiCVGE3daga2reh0aRUvey7pboF2JYm4gN6Sqhk%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%7CGary.Daniels%40microsoft.com%7C5987263ed2fb41f5bb1608d792c50c62%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139247338611958&sdata=Z9BQ%2FY22MSWTRpbccgMHh%2Fc4WzFcQm9J7vuyKbntxSE%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


PNG image

Other related posts:

  1. Home
  2. wdmaudiodev
  3. Archive
  4. 01-2020