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.