Another thing apart from the documentation is that the dynamic format
change does not work as expected in Windows 8.1 and later. Could you please
specify more on, which verbs (SET/GET) of KSPROPERTY_PIN_PROPOSEDATAFORMAT/2
should be implemented to get it right. or it would be helpful if possible,
you can update SYSVAD to demonstrate dynamic format change.
Thanks,
Zubin.
On Tue, Jun 23, 2015 at 10:12 PM, Frank Yerrace <Frank.Yerrace@xxxxxxxxxxxxx
wrote:
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.)
Regards,
Frank Yerrace
*From:* wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:
wdmaudiodev-bounce@xxxxxxxxxxxxx] *On Behalf Of *Tim Roberts
*Sent:* Tuesday, June 23, 2015 9:04 AM
*To:* wdmaudiodev@xxxxxxxxxxxxx
*Subject:* [wdmaudiodev] Re: Fwd: KSPROPERTY_PIN_PROPOSEDATAFORMAT vs
KSPROPERTY_PIN_PROPOSEDATAFORMAT2
Zubin Polra wrote:
It seems that KSPROPERTY_TYPE_SET of KSPROPERTY_PIN_PROPOSEDATAFORMAT*2*
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
KSPROPERTY_PIN_PROPOSEDATAFORMAT.
No reason, as far as I can tell. PROPOSEDDATAFORMAT should be enough. Do
you have evidence that it is not?
--
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.
