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/