The main problem is that the current implementation of the Audio
Properties Store is inconsistent. If a driver reports support of
particular data ranges immediately after installation, and then
supported data ranges are changed, raising
KSEVENT_PINCAPS_FORMATCHANGE is not always enough to reflect the
changes to the audio services. In some cases, you have to manually set
a new shared format because the shared format selected previously,
becomes unsupported. In other cases, the Advanced tab in the endpoint
audio properties displays default format combo box disabled, or even
there is no Advanced tab at all.
To get the endpoint configured properly, you have to restart the Audio
Service, restart Windows, uninstall/reinstall the driver, or even to
manually delete Audio Property Store entries.
This problem is observed from Win7 to the latest Win10 builds, with
some variations. But I know no Windows release that is able to
correctly process *any* change of data range set supported by the audio
Using unique reference strings to avoid this problem is both an
extremely ugly and definitely incorrect way. Such solution can be
recommended only as a temporary workaround, not as a permanent
The proper way is, of course, to implement a fully correct
KSEVENT_PINCAPS_FORMATCHANGE processing by the Audio Services.
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
URL to WDMAUDIODEV page: