Re: Where is my KSSTATE_STOP notification?

On Oct 25, 11:26 pm, multiben <multi...@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
"marli...@xxxxxxxxx" wrote:
On Oct 25, 9:54 pm, multiben <multi...@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
"multiben" wrote:

"marli...@xxxxxxxxx" wrote:

On Oct 25, 7:07 pm, multiben <multi...@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
"marli...@xxxxxxxxx" wrote:
On Oct 24, 5:21 pm, multiben <multi...@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
Hi There,
My problem, in a nutshell, is:

When playing an audio file with Windows Media Player and the player is
stopped within 21 seconds from the end of the file, my miniport driver never
receives any KSSTATE notifications. The port driver just stays in KSSTATE_RUN
and keeps calling GetPosition forever.

Once I actually shutdown Windows Media Player, I finally get the PAUSE ->
ACQUIRE -> STOP.

If I stop 22 seconds or more before the end then everything works fine. No
matter what file I use, regardless of length, sample rate, bit rate or
channels, the result is always the same.

I am baffled! Does anyone have any ideas as to where I could look next?
Thanks, Ben

If I recall correctly, you will not receive the STOP until you return
all the IRPs. Check your queues for any outstanding IRPs.

I have IRP functions for IRP_MJ_DEVICE_CONTROL and IRP_MJ_PNP and as far as
I can tell there are no outstanding ones when the player is stopped, but I'm
not exactly sure how to check my queue (I'm not managing my own queue).

The GetPosition() function of my IDmaChannel derived class continues to get
called even though the player has stopped. Am I correct in assuming that this
function is being called in response to an IRP received from Direct Sound? If
so, can you tell me what IRP type it is?- Hide quoted text -

- Show quoted text -

Hi,

What driver model are you using? I am pretty sure you have a data IRP
outstanding somewhere...or your are not properly completing all your
data IRPS.
But, let me know what driver model you are using....

Is it WavePCI? Are you using the GetMappping() function to get
buffers? If so, are you sure you calling ReleaseMapping() for all
buffers? Also, are you sure your counter is properly indicating that
it has played all outstanding data? If not, the caller will think you
are still holding data. Oh, are you properly handling revoked mappings
if you are using WavePCI?

You are not getting the STOP because the caller thinks you are still
processing something...

I am using a WaveCyclic model.
When you say 'counter', are you referring to the position I am returning
from IMiniportWaveCyclic::GetPosition()? I certainly believe this to be
functioning correctly.

Do you have any idea why this would only happen if the player is stopped
within 21 seconds from the end of any audio file?

THanks,
Ben

I should probably add that I don't even get a transition to KSSTATE_PAUSE.
Ben- Hide quoted text -

- Show quoted text -

Wrt the 21 second thing...I would not consider the 21 to be so
important...the problem is that the caller thinks you have not
completed all the data for one reason or another.

My feeling is that you need to do some careful logging of all the
traffic into and out of your driver.
I would start with very short files...as short as you can make
them...if possible just a couple of buffers.
Even the .25 sec chime is too long...
You need to record a very short file and start logging very carefuly
what your driver is doing.
If you are lucky the problem of you not return a counter properly will
be exposed with a short file.
When I said IRPs before....I did not realize you were using
wavecyclic...so almost certainly, your counter is the problem. The
caller uses the counter to know when to return IRPs...so what I said
is still valid...but you don't see those details.
The caller thinks your counter still needs to process part or all of
one more irps.
And for this reason it will send it back...
Let me know...I'll try to help as much as I can. Look at that
counter...prove to yourself 100% that it is correct...then we can look
at other possibilities...I just cannot think of anything else right
now.
If your code works for small files...then gradually increase the size
of the file until it fails.

Thanks for all your help so far. I will do as you suggest and start working
through very small files and increase them slowly. I will post the results of
my efforts after the weekend :)
Thanks again,
Ben- Hide quoted text -

- Show quoted text -

Yikes, I should have said, "The caller thinks your counter still needs
to process part or all of
one more irps. And for this reason, it (PortCls) will NOT send it
(the IRP) back...".
Sorry...I hope I did not confuse you. I am very tired so my typing is
terrible now.


.

Relevant Pages

  • Re: Where is my KSSTATE_STOP notification?
    ... The port driver just stays in KSSTATE_RUN ... Check your queues for any outstanding IRPs. ... I can tell there are no outstanding ones when the player is stopped, ... I am pretty sure you have a data IRP ...
    (microsoft.public.development.device.drivers)
  • Re: Where is my KSSTATE_STOP notification?
    ... The port driver just stays in KSSTATE_RUN ... Check your queues for any outstanding IRPs. ... I can tell there are no outstanding ones when the player is stopped, ... I am pretty sure you have a data IRP ...
    (microsoft.public.development.device.drivers)
  • Re: Where is my KSSTATE_STOP notification?
    ... The port driver just stays in KSSTATE_RUN ... Check your queues for any outstanding IRPs. ... I can tell there are no outstanding ones when the player is stopped, ... the caller will think you ...
    (microsoft.public.development.device.drivers)
  • Re: Where is my KSSTATE_STOP notification?
    ... The port driver just stays in KSSTATE_RUN ... Check your queues for any outstanding IRPs. ... I can tell there are no outstanding ones when the player is stopped, ... the caller will think you ...
    (microsoft.public.development.device.drivers)
  • Re: USB interrupt endpoint limitations
    ... We have our custom USB driver for it. ... I've tried to implement multiple pending IRPs in the driver but I'm not ... To implement the multiple pending IRPs on the interrupt endpoint I simply ...
    (microsoft.public.development.device.drivers)
Loading