[wdmaudiodev] Re: HLK - Audio Codec - KS Position Test errors.

  • From: "Vincent Burel \(VB-Audio\)" <vincent.burel@xxxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Mon, 7 Jan 2019 15:59:29 +0100

Hello,

 

The problem regarding setWritePacket has already been indirectly mentioned here 
in June/July 2018

Sear for subject: SYSVAD WASAPI Eclusive playback mode does not work

I also wrote an issue on GitHub about this:

https://github.com/Microsoft/Windows-driver-samples/issues/255

…always no reply on this… 

 

REM:  HLK - Audio Codec - KS Position Test errors can also be due to a problem 
in your sample position m_ullPlayPosition & m_ullWritePosition in 
CMiniportWaveRTStream::UpdatePosition

 

For your information: We have lost the last year on this SYSVAD crap without 
any useful help here: all the story is there:

https://www.facebook.com/notes/vb-audio-software/does-microsoft-care-about-audio/2061956880540508/

 

Regards

Vincent Burel

 

 

De : wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] ;
De la part de cedric demiere
Envoyé : lundi 7 janvier 2019 15:09
À : wdmaudiodev@xxxxxxxxxxxxx
Objet : [wdmaudiodev] Re: HLK - Audio Codec - KS Position Test errors.

 

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 <mailto:dmarc-noreply@xxxxxxxxxxxxx> 
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 <mailto:timr@xxxxxxxxx> 
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.

 

 


Image supprimée par l'expéditeur.

JPEG image

Other related posts:

  1. Home
  2. wdmaudiodev
  3. Archive
  4. 01-2019