One problem at a time please.
________________________________
From: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> on
behalf of Vincent Burel (VB-Audio) <vincent.burel@xxxxxxxxxxxx>
Sent: Thursday, September 19, 2019 10:57:30 PM
To: wdmaudiodev@xxxxxxxxxxxxx <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] ;
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<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%7C45f1073f66e54d71ee5b08d73d8f7f8e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045558856394643&sdata=u7mtP70qO0gwJDNJAUJ4h5Z5vXFUxZBSVpAbimh3sjU%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%7C45f1073f66e54d71ee5b08d73d8f7f8e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045558856404639&sdata=WDwSy1Fwg%2BWIKI8KhfQV9wDekWfoiCP6SvZENmZhn1w%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%7C45f1073f66e54d71ee5b08d73d8f7f8e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045558856414636&sdata=JHiFFufoIIb4t%2Fumyr%2FPrkXuIFD0vsLVXTbzbn2d3oc%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