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.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%7CGary.Daniels%40microsoft.com%7Cbb6d72262b3a44dd881c08d736ce3eed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637038131782534222&sdata=602fLjKrQRmkleazTZDvtHEWl2SxoTBCvIxjZRMHB40%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%7CGary.Daniels%40microsoft.com%7Cbb6d72262b3a44dd881c08d736ce3eed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637038131782544230&sdata=8%2B4%2FyEbIxZu1WURNx9Yg9wBXX2aAqZNjSU8CB%2BpMlDA%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
