* a driver might
change buffer size requirements on run time, depending on device's
state, protocol settings etc
Windows does not support dynamically changing buffer size requirements; the
packet size constraints are expected to be constant for a given
KSCATEGORY_AUDIO interface. This information is bubbled up to the app via the
IAudioClient3::GetSharedModeEnginePeriod API
https://docs.microsoft.com/en-us/windows/desktop/api/audioclient/nf-audioclient-iaudioclient3-getsharedmodeengineperiod
It is possible to imagine various ways to add support for dynamically changing
buffer size requirements to future versions of Windows; can you submit a
feature suggestion in Feedback Hub with some examples of device state, protocol
settings, or other driver scenarios that would benefit?
* why Microsoft started to prefer registry properties over
filter/pin property sets
Whenever there is a new need for a driver to convey information to Windows, we
try to make a considered decision about the best vehicle to convey the
information.
If, as here, the information is basically static, then interface properties are
more attractive than KSPROPERTY IOCTLs; for example, an interface property can
often be specified in the .inf, with no code necessary.
________________________________
From: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> on
behalf of Eugene Muzychenko <reg.wad@xxxxxxxxxxxxxx>
Sent: Friday, September 7, 2018 1:31:44 AM
To: Matthew van Eerde
Subject: [wdmaudiodev] Re: Other strangeness in PortCls and AudioDG
Hello Matthew,
The developer’s theory is that you are updating the
KSPROPERTY_RTAUDIO_BUFFER_WITH_NOTIFICATION implementation and then
replacing the .sys file, rather than uninstalling and reinstalling
the audio driver. This causes the audio service’s cached state to be
incorrect for the new version of your driver.
Can you try uninstalling your driver and reinstalling it?
