Hi, I would check the following two items in case you have not: 1. Make sure you are returning STATUS_SUCCESS on the transition to KSSTATE_PAUSE. 2. Carefully check your property handlers to make sure you are properly supporting all the expected properties. Are you supporting all the property sets the application requires? Also, you might be able to use KsStudio with full logging to set up a graph and switch states manually. If it happens to fail you will probably be able to diagnose the reason easily. Also, try to use GraphEdit to set up a graph and see if it works or does not work.Don't use a renderer to make the graph as simple as possible. Use, for example, the dump filter. That will eliminate many possible variables. If, for example, GraphEdit and KsStudio work, then there is a good chance there is an improperly supported property in your driver. 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. Another idea.Try the application with a sample virtual driver such as the AVStream drivers which are known good. That might or might not provide a clue depending on what the problem is. Also, try the application with another piece of hardware that has a known good certified driver. Just some ideas for you. _____ From: wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Neetu Sand Sent: Friday, September 12, 2008 4:35 AM To: wdmaudiodev@xxxxxxxxxxxxx Subject: [wdmaudiodev] KS STATE PAUSE and Streaming Hi All, 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?? I saw this behavior with WinAudio sample from microsoft using our drivers. This application uses WASAPI so there might be a problem in WASAPI APIs and stream.sys interaction. Though I am not sure where the problem is. Can anyone from microsoft shed any light on it?? Thanks, Neetu.