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

  • From: "Matthew van Eerde" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "Matthew.van.Eerde" for DMARC)
  • To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Thu, 19 Sep 2019 16:42:25 +0000

  *   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-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%7C87f00aa99600464e19e408d73d1fca78%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045079064019458&sdata=d5YnAdWXcRyGfAyuvGfqYLzUztMbC3kdB0JIlmdPw%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<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



De : wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] De la part de Dave Westacott
Envoyé : vendredi 13 septembre 2019 18:48
À : wdmaudiodev@xxxxxxxxxxxxx<mailto: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<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> On 
Behalf Of wade dawson
Sent: Friday, September 13, 2019 12:05 PM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto: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<mailto: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<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> on 
behalf of Ed Tottenham <Ed.Tottenham@xxxxxxxxx<mailto:Ed.Tottenham@xxxxxxxxx>>
Sent: Wednesday, September 11, 2019 8:37 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx
<wdmaudiodev@xxxxxxxxxxxxx<mailto: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<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx
[wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>] on 
behalf of Wade Dawson 
[Wade.Dawson@xxxxxxxxxxxxx<mailto:Wade.Dawson@xxxxxxxxxxxxx>]
Sent: 11 September 2019 16:28
To: wdmaudiodev@xxxxxxxxxxxxx<mailto: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.com%2F%3Fid%3Dx8BFSi3u061809%26from%3Dwdmaudiodev-bounce%40freelists.org%26to%3Ded.tottenham%40sadie.com%26url%3Dhttps%3A%2F%2Fwww.resplendence.com%2Fregistrar&data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7C87f00aa99600464e19e408d73d1fca78%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045079064029454&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.com%2F%3Fid%3Dx8BFSi3u061809%26from%3Dwdmaudiodev-bounce%40freelists.org%26to%3Ded.tottenham%40sadie.com%26url%3Dhttps%3A%2F%2Faka.ms%2Fo0ukef&data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7C87f00aa99600464e19e408d73d1fca78%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045079064029454&sdata=v6NnMG080HOkCbJAid78QDe%2FuDLooB7hS3nX2r1BI9w%3D&reserved=0>

________________________________

From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> on 
behalf of Ed Tottenham <Ed.Tottenham@xxxxxxxxx<mailto:Ed.Tottenham@xxxxxxxxx>>
Sent: Wednesday, September 11, 2019 3:37:46 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx
<wdmaudiodev@xxxxxxxxxxxxx<mailto: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: