[wdmaudiodev] Re: KS STATE PAUSE and Streaming

  • From: "Sam Tertzakian" <sam@xxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Tue, 16 Sep 2008 08:53:13 -0700

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.

 

Other related posts: