* ERROR: Method (IAudioClient::Initialize) call failed with code 0x8889000a
That’s AUDCLNT_E_DEVICE_IN_USE.
The testcase creates a default-mode stream and a raw-mode stream, in that
order. The default-mode stream is succeeding but the raw-mode stream is
failing. I’m going to guess that the issue is that the
KSPROPERTY_PIN_GLOBALCINSTANCES for this streaming pin is only 1. If you grab
audio ETW logs of the failure that should confirm or deny my theory.
https://matthewvaneerde.wordpress.com/2017/01/09/collecting-audio-logs-the-old-fashioned-way/
* Why MUST we support ENDPOINT_HARDWARE_SUPPORT_xxx
If you support only a single mode, a hardware volume control is optional. If
it’s there, Windows will use it. If it’s not there, Windows will insert a
volume APO near the end of the pipe.
But since you support multiple modes, the Windows audio engine will create
separate mixes for each signal processing mode. It will hand the output of each
mix to a pin instance created in that mode. At that point something will mix
the audio streams for each of the pin instances together, and then the audio
endpoint volume needs to be applied AFTER that final mix. That is why hardware
volume is required.
From: Michael Johansen<mailto:johansen.mic@xxxxxxxxx>
Sent: Tuesday, May 21, 2019 6:48 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] HLK Failure: Audio Codec - Hardware Offload of Audio
Processing Test - Certification
First failure is
Error: Verify: SUCCEEDED(pDefaultAudioStreamingRender->Initialize(NULL)) -
Value (0x8889000a)
Have included kernel trace log.
Subsequent failures:
ENDPOINT_HARDWARE_SUPPORT_XXX required support: 0x1; actual support 0x0
Why MUST we support ENDPOINT_HARDWARE_SUPPORT_xxx ????
The hardware has a DAC and ADC. That's it. The rest is handled in software.
Regards,
Michael
