Hi, What happens when you use GraphEdit? Are you setting the Status in the SRB to STATUS_PENDING when you queue the IRP (in addition to returning STATUS_SUCCESS)? (In my driver I am). What is the problem if you just work around the problem by not queueing the buffers in PAUSE? _____ From: wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Neetu Sand Sent: Monday, September 15, 2008 6:41 AM To: wdmaudiodev@xxxxxxxxxxxxx Subject: [wdmaudiodev] Re: KS STATE PAUSE and Streaming Hi Sam, Thanks for suggestions. Please see my comments below: On Sun, Sep 14, 2008 at 1:03 PM, Sam Tertzakian <sam@xxxxxxxxxxx> wrote: 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. Yes, I am doing that. Driver is working fine on XP and Vista with almost all the applications. It does not only work with the WASAPI test application that I mentioned. 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? I ran KSStudio and checked things in that as well. Properties look good and it is able to instantiate pins properly. 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. I tried two things : streaming in Pause state and canceling SRbs in PAUSE state and application started working fine after both of the things. However both of these things do not sound right to me. If there is a bug in any other part of the system then I should not be changing code in my driver to make things work right. So first thing to find out would be to check if queueing data in PAUSE state is conceptually correct or not? 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. Yes, there are lot of other drivers that are working fine with this application but what if they are not using same driver model as the one I am using? I mean if there is a bug in "stream.sys" then drivers written in "Streaming Minidriver" architecture would see that..right? Do you think that driver should stream data or cancel SRbs is pause state? I don't feel it right but I might be missing something in this whole thing! Thanks, neetu. 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.