I believe the MSDN documentation for KSPROPERTY_PIN_PROPOSEDATAFORMAT2 is a
fair bit misleading, unfortunately. Thanks for pointing this out. I’ll start
the process to get that fixed.
KSPROPERTY_PIN_PROPOSEDATAFORMAT2 is a somewhat different than
KSPROPERTY_PIN_PROPOSEDATAFORMAT and probably should have been named
differently. The sysvad sample driver demonstrates an implementation. The OS
uses the property to query the audio driver for a proposed format for a given
signal processing mode. This allows the audio driver to prefer different audio
formats for different audio signal processing modes.
(And yes, we recognize that the documentation around audio signal processing
modes is currently somewhat bleak as well. We are already in the process of
improving this, too.)
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Tim Roberts
Sent: Tuesday, June 23, 2015 9:04 AM
Subject: [wdmaudiodev] Re: Fwd: KSPROPERTY_PIN_PROPOSEDATAFORMAT vs
Zubin Polra wrote:
It seems that KSPROPERTY_TYPE_SET of KSPROPERTY_PIN_PROPOSEDATAFORMAT2 has
different meaning than KSPROPERTY_TYPE_SET of KSPROPERTY_PIN_PROPOSEDATAFORMAT
and MSDN is not specifying any thing regarding this.
Of course it does. It's right there in the documentation. PROPOSEDDATAFORMAT
takes a KSDATAFORMAT structure, so you can specify exactly one format.
PROPOSEDDATAFORMAT2 takes a KSMULTIPLE_ITEM structure, which allows the client
to submit a list of formats. The request succeeds if the driver supports any
of them. It's an optimization.
I don't understand the need of KSPROPERTY_PIN_PROPOSEDATAFORMAT2.
Why driver should support it if it is already supporting
No reason, as far as I can tell. PROPOSEDDATAFORMAT should be enough. Do you
have evidence that it is not?
Tim Roberts, timr@xxxxxxxxx<mailto:timr@xxxxxxxxx>
Providenza & Boekelheide, Inc.