[wdmaudiodev] Re: KS STATE PAUSE and Streaming

  • From: Tim Roberts <timr@xxxxxxxxx>
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Fri, 12 Sep 2008 09:47:56 -0700

Neetu Sand wrote:
> 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??

You are wrong.  Many graphs try to "pre-roll" the graph so that data is
cued up and ready to go immediately on the transition to RUN.  Thus,
some applications expect to get a few samples during PAUSE.  The stock
video renderer, as an example, will not complete the transition to
"paused" state until it gets a video frame.

A kernel streaming driver can say that it  doesn't support this by
setting KSPIN_FLAG_PROCESS_IN_RUN_STATE_ONLY in its pin descriptor.  I'm
not sure of the equivalent for straight stream-class drivers.

Why are you creating a stream-class minidriver instead of AVStream?

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


Other related posts: