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 Daves question, but Im 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/
Grab a link to the problem report and include it in the email.
Ill 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. Im sure this is not a sanctioned practice, but...
For testing purposes, Ive 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%7Cf369a8215e834f4173
d508d73d09be3f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6370449843870738
11&sdata=GGGmdJd5bu858OdE73%2BFd9Wp5bnk%2BRPUprIRALB1dzI%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%7Cf369a8215e834f4173d508d73d09be3f%7C
72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637044984387083766&sdata=3C%2BSWu
FFz2LmqVxoxPxIEZtyr7KJYjOgKKTjrde0eRE%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
