[wdmaudiodev] Re: The link between Audio Properties and the Driver Endpoint.

  • From: "Vincent Burel \(VB-Audio\)" <vincent.burel@xxxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Fri, 20 Sep 2019 07:57:30 +0200

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] De la part de Matthew van Eerde
(Redacted sender "Matthew.van.Eerde" for DMARC)
Envoyé : jeudi 19 septembre 2019 18:42
À : 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 <wdmaudiodev-bounce@xxxxxxxxxxxxx> on
behalf of Vincent Burel (VB-Audio) <vincent.burel@xxxxxxxxxxxx>
Sent: Thursday, September 19, 2019 9:37:49 AM
To: wdmaudiodev@xxxxxxxxxxxxx <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] De la part de Matthew van Eerde
(Redacted sender "Matthew.van.Eerde" for DMARC)
Envoyé : jeudi 19 septembre 2019 17:30
À : 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-a
nd-suggest-features-with-the-feedback-hub/
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmatthewva
neerde.wordpress.com%2F2016%2F09%2F26%2Freport-problems-with-logs-and-sugges
t-features-with-the-feedback-hub%2F&data=02%7C01%7CMatthew.van.Eerde%40micro
soft.com%7C87f00aa99600464e19e408d73d1fca78%7C72f988bf86f141af91ab2d7cd011db
47%7C1%7C0%7C637045079064019458&sdata=d5YnAdWXcRyGfAyuvGfqYLzUztMbC3kdB0JIlm
dPw%2FY%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 <wdmaudiodev-bounce@xxxxxxxxxxxxx> on
behalf of Vincent Burel (VB-Audio) <vincent.burel@xxxxxxxxxxxx>
Sent: Thursday, September 19, 2019 7:00:01 AM
To: wdmaudiodev@xxxxxxxxxxxxx <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

 

De : wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Dave Westacott
Envoyé : vendredi 13 septembre 2019 18:48
À : wdmaudiodev@xxxxxxxxxxxxx
Objet : [wdmaudiodev] Re: The link between Audio Properties and the Driver
Endpoint.

 

Great to have that insight Gary, very much appreciated. 

 

Dave

Westacott Organs

 

From: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> On
Behalf Of wade dawson
Sent: Friday, September 13, 2019 12:05 PM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: The link between Audio Properties and the Driver
Endpoint.

 

 Thanks very much , Gary.  This is very useful information to have - very
much appreciated!

 

-Wade

 

On Wed, Sep 11, 2019 at 1:46 PM Gary Daniels <dmarc-noreply@xxxxxxxxxxxxx>
wrote:

The endpoint name is a user setting (you can go into mmsys.cpl and modify it
manually). The generated value and the user setting are stored in the same
property key, so after creation the generated value becomes a user setting.
Because it's a user setting, on every OS upgrade or driver update it is
always brought forward. Yes, we are aware that this is sometimes an issue.
No, we don't like the current design. Yes, we have talked about strategies
to split the generated value from the user data so that a generated value
can be replaced by another generated value while also respecting the user
values. No, it's not currently scheduled work and I don't know when or if it
will ever be changed.

 

The only way for the driver to change the endpoint name in a situation like
this would be to change the reference strings used for the audio endpoints.
If the reference string changes AudioEndpointBuilder will interpret it as a
new device and will create new audio endpoints for it with the new generated
name. This can make sense in some situations, however it is going to result
in user preferences associated to the old reference string being lost. The
OS will delete the old endpoint information after 2 OS upgrades without use.
Changing the reference string also wreaks havoc on the default audio
endpoint selection algorithm. The algorithm prioritizes new endpoints
without a user selection history above old endpoints, so by changing the
reference string this device will almost certainly become the new default
for the system. Be cautious when changing the reference string. Don't have a
driver generate a new reference string for every boot, or tie the reference
string to the format, or always generate a new one for every install, or use
a different one when you resume from a hibernate than when you have a fresh
boot... These sorts of behaviors result in bugs that come to me, and a bad
user experience. If it's necessary for a one time driver update to fix a
specific bug like this, then it seems like a reasonable tradeoff.

 

In regards to deleting mmdevices keys. Do not delete the mmdevices registry
keys for customers, you'll be removing all of their user preferences, which
will anger them (and me when I get the bug reports) and break stuff.  If you
want to do it for testing purposes on a development machine, it's OK as long
as you're aware that you will lose all user preferences for audio, APO
preferences, custom names, custom icons, preferred formats, etc. 

 

The safe way to do it. Stop AudioEndpointBuilder, use regedit to take
ownership of mmdevices\audio\render and mmdevices\audio\capture. Do not take
ownership of mmdevices or mmdevices\audio. Delete all of the endpoint keys,
including render & capture. Then start audiosrv, which will also start
endpoint builder. This way when endpoint builder starts it will recreate the
render and capture keys with the correct permissions, so all of the audio
endpoints will also have the correct inherited permissions. Applications
read these registry keys in their process, so it's important that they have
the correct permissions set. Incorrect permissions could result in some
classes of applications not being able to read them, which would break audio
for those applications.

 

Gary Daniels

Windows Audio Silicon

 

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


  _____  


From: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> on
behalf of Ed Tottenham <Ed.Tottenham@xxxxxxxxx>
Sent: Wednesday, September 11, 2019 8:37 AM
To: wdmaudiodev@xxxxxxxxxxxxx <wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] Re: The link between Audio Properties and the Driver
Endpoint. 

 

Hi Wade, Thanks for the advice.

 

I was sort of assuming that just deleting everything for my device under
MMDevices\Render and MMDevices\Capture would be frowned upon. I imagined it
could leave dangling references all over the place.

 

The device is indeed a software device.

 

Thanks again

Ed

 


  _____  


From: wdmaudiodev-bounce@xxxxxxxxxxxxx [wdmaudiodev-bounce@xxxxxxxxxxxxx] on
behalf of Wade Dawson [Wade.Dawson@xxxxxxxxxxxxx]
Sent: 11 September 2019 16:28
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: The link between Audio Properties and the Driver
Endpoint.

Hi Ed.  I’m sure this is not a sanctioned practice, but...

 

For testing purposes, I’ve found that if I delete ALL subkeys FOR MY
DEVICE(s)  ONLY under ...MMDevices\Render and ..MMDevices\Capture, then the
EP builder (I assume) recreates them with the names from MediaCategories.
In my case its a USB device so its filters are created / removed upon load /
unload.  If yours is a sw device I imagine disabling / enabling via device
manager or devcon should do the trick (unless there are hanging references
in which case a reboot will be required).

 

PS.  If you're having problems manipulating the registry keys, try
https://www.resplendence.com/registrar
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fr.xdref.c
om%2F%3Fid%3Dx8BFSi3u061809%26from%3Dwdmaudiodev-bounce%40freelists.org%26to
%3Ded.tottenham%40sadie.com%26url%3Dhttps%3A%2F%2Fwww.resplendence.com%2Freg
istrar&data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7C87f00aa99600464e19
e408d73d1fca78%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6370450790640294
54&sdata=KnCISdfytE3eJTmPt0Cw4wHERLElLz0AahAnyzEu4gQ%3D&reserved=0>  - a
truly lovely bit of software (Thanks Daniel!)

PPS.  I use this tool to search for a value string that only my devices will
contain, usb vid/pid, serial, etc in the ...Render or ..Capture SubTree,
then group select all the found entries and delete them.

 

Again, Im sure this is non-sanctioned and I would certainly not recommend
this as a production-ready solution, but my experience has been favorable so
far using 10/1809 and 10/1903.

 

 

 

 

Get Outlook for iOS
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fr.xdref.c
om%2F%3Fid%3Dx8BFSi3u061809%26from%3Dwdmaudiodev-bounce%40freelists.org%26to
%3Ded.tottenham%40sadie.com%26url%3Dhttps%3A%2F%2Faka.ms%2Fo0ukef&data=02%7C
01%7CMatthew.van.Eerde%40microsoft.com%7C87f00aa99600464e19e408d73d1fca78%7C
72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045079064029454&sdata=v6NnMG08
0HOkCbJAid78QDe%2FuDLooB7hS3nX2r1BI9w%3D&reserved=0> 


  _____  


From: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> on
behalf of Ed Tottenham <Ed.Tottenham@xxxxxxxxx>
Sent: Wednesday, September 11, 2019 3:37:46 AM
To: wdmaudiodev@xxxxxxxxxxxxx <wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] The link between Audio Properties and the Driver
Endpoint. 

 

Hello,

 

I'm hoping that someone can help here.

 

I am trying to find the link between the Endpoint information used in a WDM
Audio Driver and the Audio Properties for an endpoint.

 

When the driver is installed, the AddReg section in the .inf file causes the
EndPoint names top be written to
HKLM\System\CurrentControlSet\Control\MediaCategories\{EndpointGuid}\Name.

 

The Audio Control Panel gets all its information using the MMDeviceApi which
gets all its information from
HKLM\Software\Microsoft\Windows\CurrentVersion\MMDevices\Audio.

 

There was a problem in our .inf file which meant that in the update to 1903
the EndPoint Names weren't added to the registry. All endpoints were given a
default name of "Digital Output" or "Digital Input" in the Audio Properties.
This is now what is retrieved by the MMDeviceAPI and displayed in the Audio
Control Panel.

 

Reinstalling the driver with a corrected .inf file writes the names
correctly to the MediaCategories section of the registry, but the MMDevices
is not updated.

 

I'd like to write a simple command line program to correct the names but I
can see nothing in the information returned by the MMDevicesApi which links
to the MediaCategories section to be able to retrieve the intended names for
the endpoints.

 

Am I on completely the wrong path? Is there a better way of updating the
endpoint names in the MMDevices section? 

 

Many thanks in advance

Ed Tottenham

 




 

-- 

Wade Dawson

DT Multimedia

Other related posts: