* In AVStream, it's the first format in the list
Um… certainly not for audio. (I don’t know what the story is for video.)
* Some other method
Some of the HLK tests send a data intersection request with the full set of the
driver’s supported data ranges as payload. I suppose this could be considered
as a way to query a “preferred format,” though it is not as explicit as
KSPROPERTY_PIN_PROPOSEDATAFORMAT/GET (note that “propose” is a verb in this
context.)
If you’re not getting a GET request, that’s unexpected, and we should try to
figure out why.
________________________________
From: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> on
behalf of Tim Roberts <timr@xxxxxxxxx>
Sent: Monday, September 25, 2017 9:45:49 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: Device Formats
Matthew van Eerde (Redacted sender Matthew.van.Eerde for DMARC) wrote:
KSPROPERTY_PIN_PROPOSEDATAFORMAT/KSPROPERTY_TYPE_GET was added in Windows 7, so
it should be working in Windows 8.1.
I hear what you're saying, but I don't see it. I have exactly one format in my
speaker tables (48000-Mono-16), and the Audio Engine insists on sending me
44100-Stereo-16, which I naturally reject. The SysVad and MSVAD samples don't
even offer GET support for KSPROPERTY_PIN_PROPOSEDDATAFORMAT, so there must be
some other method of communicating a "preferred format" without using that
request. In AVStream, it's the first format in the list.
Is it possible PortCls is intercepting that request and supplying something on
my behalf? Someone, somewhere is using some criteria to decide what format I
should get, and it's not meshing with my offerings.
--
Tim Roberts, timr@xxxxxxxxx<mailto:timr@xxxxxxxxx>
Providenza & Boekelheide, Inc.
