[wdmaudiodev] Re: KS STATE PAUSE and Streaming
- From: "Neetu Sand" <neetu.freelist@xxxxxxxxx>
- To: wdmaudiodev@xxxxxxxxxxxxx
- Date: Mon, 15 Sep 2008 19:10:43 +0530
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:
