[wdmaudiodev] Re: KS STATE PAUSE and Streaming

  • From: AI Developer <developer@xxxxxxxxxxxxxxxx>
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Tue, 16 Sep 2008 10:40:06 +0530


Are you saying that the driver should "stream" when pin state is "Pause"?

That does not sound right to me.

From the DDK:

Transition Description
Stop to pause Allocate resources. The read SRBs typically are queued after the transition to the pause state has completed.
Pause to run Begin streaming.
Run to pause Stop streaming. The outstanding read SRBs remain in the driver-maintained queue.
Pause to stop Deallocate resources and complete all outstanding read SRBs. SRBs that have not been filled with an image are completed with zero length in the DataUsed member of the KSSTREAM_HEADER structure.


State Description
KSSTATE_STOP Using absolute minimum of resources. No outstanding data SRBs at the driver.
KSSTATE_ACQUIRE Acquiring resources. Allocating all needed resources such as bandwidth on USB and IEEE 1394.
KSSTATE_PAUSE Preparing to instantly make transition to the Run state.
KSSTATE_RUN Streaming. Fill buffers and complete SRBs through CompleteStreamSRB.


Both of these seem to indicate that streaming should happen only when the state is KSSTATE_RUN.


Tim Roberts wrote:
Neetu Sand wrote:

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.


I tried two things : streaming in Pause state and canceling SRbs in  PAUSE state and application started working fine after both of the things. However both of these things do not sound right to me. If there is a bug in any other part of the system then I should not be changing code in my driver to make things work right. So first thing to find out would be to check if queueing data in PAUSE state is conceptually correct or not?

Yes, it is conceptually correct.  The renderer will not render audio data until the graph transitions to RUN, so you will only be able to stream data until the queue fills, then the graph will truly "pause".  In the meantime, when the graph DOES transition to RUN, data is all ready to go with no additional latency.  It's a "feature".

When you start playing a movie, you will often get a single "billboard" frame in the renderer so there is something to see that is more interesting than a black screen.  That "billboard" frame comes from streaming data in the PAUSE state.  As I said, the stock renderer will not allow the graph to transition to RUN until it has received a billboard frame (unless it has been told that the graph cannot pre-roll).

Yes, there are lot of other drivers that are working fine with this application but what if they are not using same driver model as the one I am using? I mean if there is a bug in "stream.sys" then drivers written in "Streaming Minidriver" architecture would see that..right?

It's not a bug.  It's a feature.  ;)

Do you think that driver should stream data or cancel SRbs is pause state? I don't feel it right but I might be missing something in this whole thing!

You should stream.
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.

****************** WDMAUDIODEV addresses: Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx URL to WDMAUDIODEV page: http://www.wdmaudiodev.com/

Other related posts: