[wdmaudiodev] Re: KS STATE PAUSE and Streaming
- From: "Sam Tertzakian" <sam@xxxxxxxxxxx>
- To: <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Sun, 14 Sep 2008 00:33:19 -0700
Hi,
I would check the following two items in case you have not:
1. Make sure you are returning STATUS_SUCCESS on the transition to
KSSTATE_PAUSE.
2. Carefully check your property handlers to make sure you are properly
supporting all the expected properties. Are you supporting all the property
sets the application requires?
Also, you might be able to use KsStudio with full logging to set up a graph
and switch states manually. If it happens to fail you will probably be able
to diagnose the reason easily.
Also, try to use GraphEdit to set up a graph and see if it works or does not
work.Don't use a renderer to make the graph as simple as possible. Use, for
example, the dump filter. That will eliminate many possible variables.
If, for example, GraphEdit and KsStudio work, then there is a good chance
there is an improperly supported property in your driver.
Another idea.don't queue the buffers in pause mode and see what happens.
(Return STATUS_CANCELLED or something). Perhaps the application is waiting
for those two buffers to return before going into a RUN state. I am not
saying this is the solution.just another data point in your investigation.
Another idea.Try the application with a sample virtual driver such as the
AVStream drivers which are known good. That might or might not provide a
clue depending on what the problem is. Also, try the application with
another piece of hardware that has a known good certified driver.
Just some ideas for you.
_____
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Neetu Sand
Sent: Friday, September 12, 2008 4:35 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] KS STATE PAUSE and Streaming
Hi All,
I have been working on investigating a bug with a application and a driver
that I have written. The driver has been written using "Streaming
MiniDriver" architecture. Here is what I see:
1. Application opens a stream in driver for render.
2. Application sets state to ACQUIRE->PAUSE.
3. Application queues 2 SRBs to stream. Here driver simply queues those SRBs
so that as soon as the state is changed to RUN it can start streaming.
4. On the other hand application does not change state to RUN and start
waiting for the return of SRBs. This eventually results in a timeout and
SRBs are canceled and returned.
I feel this is a wrong behavior from application's side because it is not
changing the driver state to RUN and queuing SRBs and expecting them to
return. Am I wrong in my understanding here??
I saw this behavior with WinAudio sample from microsoft using our drivers.
This application uses WASAPI so there might be a problem in WASAPI APIs and
stream.sys interaction. Though I am not sure where the problem is.
Can anyone from microsoft shed any light on it??
Thanks, Neetu.
Other related posts:
