[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
URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/
Other related posts:
