Hello Matthew and Tim,
Thanks for the tips.
I’ve added some logs on ‘setWritePacket’ and the error come from
‘STATUS_DATA_LATE_ERROR’.
I roughly understand the error. The ‘current’ packet index is not the same on
driver and OS.
This packet index is updated on ‘TimerNotifyRt’ and both method are called by
the OS, so how packet index can be different ?
From the log (below), it seems that we not receive ‘setWritePacket’ fast enough
and get two ‘TimerNotifyRt’ call.
Logs:
//When it works
Update m_llPacketCounter to 3
SetWritePacket : receive 3, expect 3. OK
Update m_llPacketCounter to 4
SetWritePacket : receive 4, expect 4. OK
//When it doesn’t work
Update m_llPacketCounter to 5
Update m_llPacketCounter to 6
SetWritePacket : receive 5, expect 6. Error 1117.
Is this the normal behavior ?
Did you know how to handle this case correctly ?
Regards,
Demière Cédric.
De : Matthew van Eerde
Envoyé le :vendredi 4 janvier 2019 20:14
À : wdmaudiodev@xxxxxxxxxxxxx
Objet :[wdmaudiodev] Re: HLK - Audio Codec - KS Position Test errors.
Good idea. Can you submit it as a feature suggestion in Feedback Hub and send
me a link?
Another way to get some transparency is to look at ETW logs from portcls, which
should reveal (a) whether the miniport was invoked and (b) what it returned
(the status code, not the mapped error result.)
From: Tim Roberts
Sent: Friday, January 4, 2019 10:44 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: HLK - Audio Codec - KS Position Test errors.
cedric demiere wrote:
Successfully instantiated KSPIN_DATAFLOW_IN pin\
KSPIN_DATAFLOW_IN pin is currently in state KSSTATE_STOP; want it to be in
state KSSTATE_PAUSE
Setting KSPIN_DATAFLOW_IN pin to state KSSTATE_ACQUIRE
Setting KSPIN_DATAFLOW_IN pin to state KSSTATE_PAUSE
KSPIN_DATAFLOW_IN pin is currently in state KSSTATE_PAUSE; want it to be in
state KSSTATE_RUN
Setting KSPIN_DATAFLOW_IN pin to state KSSTATE_RUN
Win32BoolSucceeded(pPin->SetPropertySimple(KSPROPSETID_RtAudio,
KSPROPERTY_RTAUDIO_SETWRITEPACKET, &dp->WritePacketInfo,
sizeof(dp->WritePacketInfo))) - Value (1117)
avcore\audiocore\test\wdmaudio\portcls\kspostst\pintest.cpp Line: 2340
******************
And, as an unrelated side note to those Redmond folks who are listening. I
heartily applaud the new philosophy within the kernel groups to release
subsystems as open source. Having the source for KMDF and friends, for
example, is a huge win for debugging and answering tricky questions. It would
be a HUGE benefit to the driver community if the WHQL/HCK/HLK test suites could
be released in source form as well. We have the file name and line number, but
that information is of absolutely no use without the source. I, personally,
have single-stepped through the tests in windbg to isolate what turned out to
be a test bug in the Media Foundation tests, but that would not have been
necessary if I could have gone to github to look up the tests.
Even more, being able to see what the tests expect would help driver writers
answer that most difficult of questions, "what do I really have to support to
be treated as an X device?" It just seems unfair to have to meet the
expectations of a test we can't actually inspect.
--
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.
--
