[wdmaudiodev] Re: KS STATE PAUSE and Streaming
- From: Tim Roberts <timr@xxxxxxxxx>
- To: wdmaudiodev@xxxxxxxxxxxxx
- Date: Wed, 17 Sep 2008 09:46:41 -0700
AI Developer wrote:
>
> Are you sure about that? Sounds like a bug in the renderer if it
> expects a frame in paused state.
I am absolutely positive. This is a well-known strangeness in
DirectShow. You can check the DirectShow code in CBaseRenderer. It
will not complete the transition to "paused" state until it either
receives a frame, or gets an indication that the upstream filter cannot
deliver one.
For a KS source, that's done by setting
KSPIN_FLAG_PROCESS_IN_RUN_STATE_ONLY in the the Flags member of
KSPIN_DESCRIPTOR_EX:
http://msdn.microsoft.com/en-us/library/aa509735.aspx
For a user-mode filter, that's done by returning VFW_S_CANT_CUE from
IMediaFilter::GetState:
http://msdn.microsoft.com/en-us/library/ms783300.aspx
As I said, the renderer relies on this behavior to put up a pretty
"post" frame while the graph is still preparing. This was done because
of network latency. When you are streaming a video from a network
server somewhere, it makes a better user experience if you can display
the first frame of the movie while you pre-fetch enough frames for
smooth playback.
> Seeing Neetu's later comment about Cancel request handling, could it
> be that in your case also, a cancel request is not being handled
> correctly? Perhaps the render is waiting for the request to be cancelled?
Not in the video case. I guarantee it.
> As for danger - yes there is a real danger. A lot of applications
> submit buffers in pause state, so that the driver has a queue of
> buffers ready when it switches to run state. Also, this way, the
> client could ensure that there's going to be enough "backup" of
> buffers during the time it takes to complete the request and to submit
> a new one. Reduces chances of buffer underruns.
Yes, but you're talking about "steady state" operation here. The
operation at startup is kind of a corner case. On the other hand, you
have convinced me that I could not possibly have been correct for the
audio case. The video case is different.
> And of course, the WHQL tests will fail your driver (I know this as a
> fact for audio drivers) if you try to stream in paused state!
Yes, it appears that I erred in attempting to extrapolate from the video
case to his audio behavior...
--
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.
Other related posts:
