[wdmaudiodev] Re: Other strangeness in PortCls and AudioDG

  • From: "Matthew van Eerde" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "Matthew.van.Eerde" for DMARC)
  • To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Fri, 7 Sep 2018 13:39:35 +0000

  *   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.

Yes, I just replace driver file and restart the driver in a debugging
process, if there were no changes in supported property sets and/or
property values in the Registry.

Can you try uninstalling your driver and reinstalling it?

Of course, reinstallation fixes the behavior. But a driver might
change buffer size requirements on run time, depending on device's
state, protocol settings etc. Using
DEVPKEY_KsAudio_PacketSize_Constraints[2] requires to re-enabling the
interface and rebuild endpoint cache.

BTW, why Microsoft started to prefer registry properties over
filter/pin property sets? A property request can be issued anytime to
obtain current device/driver state and/or requirements/constraints.
AudioDG might issue an appropriate request before allocating the
buffer, and no "alignment dance" would be needed.

Regards,
Eugene

******************

WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe:  mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx

URL to WDMAUDIODEV page:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.wdmaudiodev.com%2F&amp;data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7Ca08ae7119dc74e079e9908d6149c6b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636719059410764457&amp;sdata=7y41H%2FwRduMAcaJhuNOUUpLhwbWV9v%2BxxXsVBPibkVo%3D&amp;reserved=0

Other related posts: