Tim,
Are you saying that the driver should "stream" when pin state is
"Pause"?
That does not sound right to me.
From the DDK:
---
| Transition |
Description |
| Stop to pause |
Allocate resources. The read SRBs typically are queued after
the transition to the pause state has completed. |
| Pause to run |
Begin streaming. |
| Run to pause |
Stop streaming. The outstanding read SRBs remain in the
driver-maintained queue. |
| Pause to stop |
Deallocate resources and complete all outstanding read SRBs.
SRBs that have not been filled with an image are completed with zero
length in the DataUsed member of the KSSTREAM_HEADER
structure. |
and:
| State |
Description |
| KSSTATE_STOP |
Using absolute minimum of resources. No outstanding data SRBs
at the driver. |
| KSSTATE_ACQUIRE |
Acquiring resources. Allocating all needed resources such as
bandwidth on USB and IEEE 1394. |
| KSSTATE_PAUSE |
Preparing to instantly make transition to the Run state. |
| KSSTATE_RUN |
Streaming. Fill buffers and complete SRBs through CompleteStreamSRB. |
---
Both of these seem to indicate that streaming should happen only when
the state is KSSTATE_RUN.
Thanks.
Devendra.
Tim Roberts wrote:
Neetu Sand wrote:
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?
Yes, it is conceptually correct. The renderer will not render audio
data until the graph transitions to RUN, so you will only be able to
stream data until the queue fills, then the graph will truly "pause".
In the meantime, when the graph DOES transition to RUN, data is all
ready to go with no additional latency. It's a "feature".
When you start playing a movie, you will often get a single "billboard"
frame in the renderer so there is something to see that is more
interesting than a black screen. That "billboard" frame comes from
streaming data in the PAUSE state. As I said, the stock renderer will
not allow the graph to transition to RUN until it has received a
billboard frame (unless it has been told that the graph cannot
pre-roll).
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?
It's not a bug. It's a feature. ;)
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!
You should stream.
--
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/
|
