Hi,
I have implemented an AVStream mini-driver for streaming RGB data from a
device. The streaming works fine with GraphEdit.exe, Windows Movie Maker,
Scanner & Camera Wizard and even with Windows Messenger.
The problem i am facing is the time delay that Windows Messenger (WM) takes
to close the “Audio Tuning Wizard” while streaming RGB data from my device.
Using KsStudio.exe, i observed that WM is sending IRP_MJ_DEVICE_CONTROL
(IOCTL_KS_READ_STREAM) periodically to read stream data from the capture pin
of my mini-driver. But while closing the “Audio Tuning Wizard” it takes
nearly 10 seconds to issue a “pin close” to my capture pin.
I also checked the behavior of msdv.sys (for a different device) through
Windows Messenger. All the IOCTL_KS_READ_STREAM requests seem to be failing
with STATUS_CANCELLED when the wizard is closed. This means that even my
mini-driver also needs to return STATUS_CANCELLED somehow.
My approach is as follows:
- My Pin Process funtion returns STATUS_PENDING
- Later when data is available (i mantain cloned stream pointers), i call
KsPinAttemptProcessing () to make the data available for processing to
applications
- When the filter graph is changing status to KSSTATE_STOP i delete all the
cloned pointers
But, besides all these i need to cancel the IRPs associated with the stream
pointers. Can somebody give me some ideas on how to do is? Any
ideas/pointers will be very helpful!
Regards,
Hari.
Cricket World Cup 2003- News, Views and Match Reports.
http://server1.msn.co.in/msnspecials/worldcup03/
There are couple of things that I can think of. I have no idea whether or not it will be helpful,
but this is what I would try.
-
when deleting clone stream pointers make sure that they do not contain any flags, which may
indicate that the stream pointer is of any use. In particular make sure that
KSSTREAMPOINTER::KSSTREAM_HEADER::OptionsFlags does NOT have
KSSTREAM_HEADER_OPTIONSF_DURATIONVALID and KSSTREAM_HEADER_OPTIONSF_TIMEVALID flags set. Also make
sure that the size of the packet is zero (DataUsed).
-
immedeately before deleting stream pointer get associated IRP KsStreamPointerGetIrp and set its
status to what you want it to be set to.
Hope it helps,
– Max.
— Hariharan Krishnamurthy wrote:
> Hi,
>
> I have implemented an AVStream mini-driver for streaming RGB data from a
> device. The streaming works fine with GraphEdit.exe, Windows Movie Maker,
> Scanner & Camera Wizard and even with Windows Messenger.
>
> The problem i am facing is the time delay that Windows Messenger (WM) takes
> to close the “Audio Tuning Wizard” while streaming RGB data from my device.
> Using KsStudio.exe, i observed that WM is sending IRP_MJ_DEVICE_CONTROL
> (IOCTL_KS_READ_STREAM) periodically to read stream data from the capture pin
> of my mini-driver. But while closing the “Audio Tuning Wizard” it takes
> nearly 10 seconds to issue a “pin close” to my capture pin.
>
> I also checked the behavior of msdv.sys (for a different device) through
> Windows Messenger. All the IOCTL_KS_READ_STREAM requests seem to be failing
> with STATUS_CANCELLED when the wizard is closed. This means that even my
> mini-driver also needs to return STATUS_CANCELLED somehow.
>
> My approach is as follows:
>
> 1) My Pin Process funtion returns STATUS_PENDING
> 2) Later when data is available (i mantain cloned stream pointers), i call
> KsPinAttemptProcessing () to make the data available for processing to
> applications
> 3) When the filter graph is changing status to KSSTATE_STOP i delete all the
> cloned pointers
>
> But, besides all these i need to cancel the IRPs associated with the stream
> pointers. Can somebody give me some ideas on how to do is? Any
> ideas/pointers will be very helpful!
>
> Regards,
> Hari.
>
> _______________
> Cricket World Cup 2003- News, Views and Match Reports.
> http://server1.msn.co.in/msnspecials/worldcup03/
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@yahoo.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Do you Yahoo!?
Yahoo! Platinum - Watch CBS’ NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Hi Max,
Thanks for the reply. I have already experimented both the approaches that
you have mentioned without any success. Strangely, msdv.sys is able to
CANCEL the read operations from client applications. Wonder what approach
it uses!
Hari.
From: Max Paklin
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: Cancelling streaming problem
>Date: Mon, 17 Mar 2003 12:35:19 -0800 (PST)
>
>There are couple of things that I can think of. I have no idea whether or
>not it will be helpful,
>but this is what I would try.
>
>1. when deleting clone stream pointers make sure that they do not contain
>any flags, which may
>indicate that the stream pointer is of any use. In particular make sure
>that
>KSSTREAMPOINTER::KSSTREAM_HEADER::OptionsFlags does NOT have
>KSSTREAM_HEADER_OPTIONSF_DURATIONVALID and
>KSSTREAM_HEADER_OPTIONSF_TIMEVALID flags set. Also make
>sure that the size of the packet is zero (DataUsed).
>
>2. immedeately before deleting stream pointer get associated IRP
>KsStreamPointerGetIrp and set its
>status to what you want it to be set to.
>
>Hope it helps,
>– Max.
>
>
>
>— Hariharan Krishnamurthy wrote:
> > Hi,
> >
> > I have implemented an AVStream mini-driver for streaming RGB data from a
> > device. The streaming works fine with GraphEdit.exe, Windows Movie
>Maker,
> > Scanner & Camera Wizard and even with Windows Messenger.
> >
> > The problem i am facing is the time delay that Windows Messenger (WM)
>takes
> > to close the “Audio Tuning Wizard” while streaming RGB data from my
>device.
> > Using KsStudio.exe, i observed that WM is sending IRP_MJ_DEVICE_CONTROL
> > (IOCTL_KS_READ_STREAM) periodically to read stream data from the capture
>pin
> > of my mini-driver. But while closing the “Audio Tuning Wizard” it takes
> > nearly 10 seconds to issue a “pin close” to my capture pin.
> >
> > I also checked the behavior of msdv.sys (for a different device) through
> > Windows Messenger. All the IOCTL_KS_READ_STREAM requests seem to be
>failing
> > with STATUS_CANCELLED when the wizard is closed. This means that even
>my
> > mini-driver also needs to return STATUS_CANCELLED somehow.
> >
> > My approach is as follows:
> >
> > 1) My Pin Process funtion returns STATUS_PENDING
> > 2) Later when data is available (i mantain cloned stream pointers), i
>call
> > KsPinAttemptProcessing () to make the data available for processing to
> > applications
> > 3) When the filter graph is changing status to KSSTATE_STOP i delete all
>the
> > cloned pointers
> >
> > But, besides all these i need to cancel the IRPs associated with the
>stream
> > pointers. Can somebody give me some ideas on how to do is? Any
> > ideas/pointers will be very helpful!
> >
> > Regards,
> > Hari.
> >
> > _______________
> > Cricket World Cup 2003- News, Views and Match Reports.
> > http://server1.msn.co.in/msnspecials/worldcup03/
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@yahoo.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>Do you Yahoo!?
>Yahoo! Platinum - Watch CBS’ NCAA March Madness, live on your desktop!
>http://platinum.yahoo.com
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
_________________________________________________________________
Cricket - World Cup 2003 http://server1.msn.co.in/msnspecials/worldcup03/
News, Views and Match Reports.
Hi,
If i set the IRP status to STATUS_CANCELLED as mentioned in your
approach[2], i was able to cancel the IRPs associated with the pending
buffers. This is what i think msdv.sys is also doing because i observed the
IRPs using KsStudio and the logs for MSDV and my driver look similar. But
Windows Messenger is still waiting for nearly 10 seconds for the buffers to
get complete.
I have also observed that if i return STATUS_CANCELLED from the PinState
function while transitioning to KSSTATE_STOP then Windows Messenger does not
take so much time. But using this approach creates further complications,
my filter graph when run through Graphedit application does not work
correctly. It succeeds during the first run but after stopping the graph if
i run again then it fails.
Any suggestions on this will be very helpful.
Hari.
There are couple of things that I can think of. I have no idea whether or
not it will be helpful,
but this is what I would try.
-
when deleting clone stream pointers make sure that they do not contain
any flags, which may
indicate that the stream pointer is of any use. In particular make sure
that
KSSTREAMPOINTER::KSSTREAM_HEADER::OptionsFlags does NOT have
KSSTREAM_HEADER_OPTIONSF_DURATIONVALID and
KSSTREAM_HEADER_OPTIONSF_TIMEVALID flags set. Also make
sure that the size of the packet is zero (DataUsed).
-
immedeately before deleting stream pointer get associated IRP
KsStreamPointerGetIrp and set its
status to what you want it to be set to.
Hope it helps,
– Max.
— Hariharan Krishnamurthy wrote:
> > Hi,
> >
> > I have implemented an AVStream mini-driver for streaming RGB data from a
> > device. The streaming works fine with GraphEdit.exe, Windows Movie
>Maker,
> > Scanner & Camera Wizard and even with Windows Messenger.
> >
> > The problem i am facing is the time delay that Windows Messenger (WM)
>takes
> > to close the “Audio Tuning Wizard” while streaming RGB data from my
>device.
> > Using KsStudio.exe, i observed that WM is sending IRP_MJ_DEVICE_CONTROL
> > (IOCTL_KS_READ_STREAM) periodically to read stream data from the capture
>pin
> > of my mini-driver. But while closing the “Audio Tuning Wizard” it takes
> > nearly 10 seconds to issue a “pin close” to my capture pin.
> >
> > I also checked the behavior of msdv.sys (for a different device) through
> > Windows Messenger. All the IOCTL_KS_READ_STREAM requests seem to be
>failing
> > with STATUS_CANCELLED when the wizard is closed. This means that even
>my
> > mini-driver also needs to return STATUS_CANCELLED somehow.
> >
> > My approach is as follows:
> >
> > 1) My Pin Process funtion returns STATUS_PENDING
> > 2) Later when data is available (i mantain cloned stream pointers), i
>call
> > KsPinAttemptProcessing () to make the data available for processing to
> > applications
> > 3) When the filter graph is changing status to KSSTATE_STOP i delete all
>the
> > cloned pointers
> >
> > But, besides all these i need to cancel the IRPs associated with the
>stream
> > pointers. Can somebody give me some ideas on how to do is? Any
> > ideas/pointers will be very helpful!
> >
> > Regards,
> > Hari.
> >
> > _______________
> > Cricket World Cup 2003- News, Views and Match Reports.
> > http://server1.msn.co.in/msnspecials/worldcup03/
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@yahoo.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>Do you Yahoo!?
>Yahoo! Platinum - Watch CBS’ NCAA March Madness, live on your desktop!
>http://platinum.yahoo.com
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
_________________________________________________________________
Cricket World Cup 2003 http://server1.msn.co.in/msnspecials/worldcup03/
News, Views and Match Reports.
I have even tried KsStreamPointerSetStatusCode () with STATUS_CANCELLED. In
this case the IRPs are successfully getting CANCELLED, but still messenger
tries to send IOCTL_READ_STREAM. This is failing with error: “INVALID DEVICE
REQUEST”. Should my mini-driver implement any events to indicate that there
are no more data buffers left to be processed?
Hari.
Hi,
If i set the IRP status to STATUS_CANCELLED as mentioned in your
approach[2], i was able to cancel the IRPs associated with the pending
buffers. This is what i think msdv.sys is also doing because i observed
the IRPs using KsStudio and the logs for MSDV and my driver look similar.
But Windows Messenger is still waiting for nearly 10 seconds for the
buffers to get complete.
I have also observed that if i return STATUS_CANCELLED from the PinState
function while transitioning to KSSTATE_STOP then Windows Messenger does
not take so much time. But using this approach creates further
complications, my filter graph when run through Graphedit application does
not work correctly. It succeeds during the first run but after stopping
the graph if i run again then it fails.
Any suggestions on this will be very helpful.
Hari.
>There are couple of things that I can think of. I have no idea whether or
>not it will be helpful,
>but this is what I would try.
>
>1. when deleting clone stream pointers make sure that they do not contain
>any flags, which may
>indicate that the stream pointer is of any use. In particular make sure
>that
>KSSTREAMPOINTER::KSSTREAM_HEADER::OptionsFlags does NOT have
>KSSTREAM_HEADER_OPTIONSF_DURATIONVALID and
>KSSTREAM_HEADER_OPTIONSF_TIMEVALID flags set. Also make
>sure that the size of the packet is zero (DataUsed).
>
>2. immedeately before deleting stream pointer get associated IRP
>KsStreamPointerGetIrp and set its
>status to what you want it to be set to.
>
>Hope it helps,
>– Max.
>
>
>
>— Hariharan Krishnamurthy wrote:
>> > Hi,
>> >
>> > I have implemented an AVStream mini-driver for streaming RGB data from
>>a
>> > device. The streaming works fine with GraphEdit.exe, Windows Movie
>>Maker,
>> > Scanner & Camera Wizard and even with Windows Messenger.
>> >
>> > The problem i am facing is the time delay that Windows Messenger (WM)
>>takes
>> > to close the “Audio Tuning Wizard” while streaming RGB data from my
>>device.
>> > Using KsStudio.exe, i observed that WM is sending IRP_MJ_DEVICE_CONTROL
>> > (IOCTL_KS_READ_STREAM) periodically to read stream data from the
>>capture pin
>> > of my mini-driver. But while closing the “Audio Tuning Wizard” it
>>takes
>> > nearly 10 seconds to issue a “pin close” to my capture pin.
>> >
>> > I also checked the behavior of msdv.sys (for a different device)
>>through
>> > Windows Messenger. All the IOCTL_KS_READ_STREAM requests seem to be
>>failing
>> > with STATUS_CANCELLED when the wizard is closed. This means that even
>>my
>> > mini-driver also needs to return STATUS_CANCELLED somehow.
>> >
>> > My approach is as follows:
>> >
>> > 1) My Pin Process funtion returns STATUS_PENDING
>> > 2) Later when data is available (i mantain cloned stream pointers), i
>>call
>> > KsPinAttemptProcessing () to make the data available for processing to
>> > applications
>> > 3) When the filter graph is changing status to KSSTATE_STOP i delete
>>all the
>> > cloned pointers
>> >
>> > But, besides all these i need to cancel the IRPs associated with the
>>stream
>> > pointers. Can somebody give me some ideas on how to do is? Any
>> > ideas/pointers will be very helpful!
>> >
>> > Regards,
>> > Hari.
>> >
>> > _______________
>> > Cricket World Cup 2003- News, Views and Match Reports.
>> > http://server1.msn.co.in/msnspecials/worldcup03/
>> >
>> >
>> >
>> > —
>> > You are currently subscribed to ntdev as: xxxxx@yahoo.com
>> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>>Do you Yahoo!?
>>Yahoo! Platinum - Watch CBS’ NCAA March Madness, live on your desktop!
>>http://platinum.yahoo.com
>>
>>
>>—
>>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>Cricket World Cup 2003 http://server1.msn.co.in/msnspecials/worldcup03/
>News, Views and Match Reports.
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
Cricket World Cup 2003- News, Views and Match Reports.
http://server1.msn.co.in/msnspecials/worldcup03/
Failing state transitions going from “active” states to “inactive” is not a good idea. It
typically leaves the graph and/or filter and/or pin in question in some sort of limbo state. Any
further attempts to break out of this state usually fail. Reconnecting pins or rebuilding graph
solves the problem.
Regarding your problem of huge delay between state transition to stopped and closing of the pin.
The only other thing I can think of is making sure that you reject any stream pointers received by
the pin after it makes state transition from running or paused state.
I saw the cases when AVStream was sending stream pointers to the pin that was in paused (when pin
descriptor set process-in-running-state-only flag) and even stopped state. If you flush your queue
upon transition to stopped state and at the same time continue to accept and queue new stream
pointers after the pin was stopped then those stream pointers will be stuck in your queue forever.
In that case I would expect the application owning the graph to hung, but maybe you have timeout
handlers set on stream pointers and you cancel them yourself in 10 seconds. Just a guess.
– Max.
— Hariharan Krishnamurthy wrote:
> Hi,
>
> If i set the IRP status to STATUS_CANCELLED as mentioned in your
> approach[2], i was able to cancel the IRPs associated with the pending
> buffers. This is what i think msdv.sys is also doing because i observed the
> IRPs using KsStudio and the logs for MSDV and my driver look similar. But
> Windows Messenger is still waiting for nearly 10 seconds for the buffers to
> get complete.
>
> I have also observed that if i return STATUS_CANCELLED from the PinState
> function while transitioning to KSSTATE_STOP then Windows Messenger does not
> take so much time. But using this approach creates further complications,
> my filter graph when run through Graphedit application does not work
> correctly. It succeeds during the first run but after stopping the graph if
> i run again then it fails.
>
> Any suggestions on this will be very helpful.
>
> Hari.
>
> >There are couple of things that I can think of. I have no idea whether or
> >not it will be helpful,
> >but this is what I would try.
> >
> >1. when deleting clone stream pointers make sure that they do not contain
> >any flags, which may
> >indicate that the stream pointer is of any use. In particular make sure
> >that
> >KSSTREAMPOINTER::KSSTREAM_HEADER::OptionsFlags does NOT have
> >KSSTREAM_HEADER_OPTIONSF_DURATIONVALID and
> >KSSTREAM_HEADER_OPTIONSF_TIMEVALID flags set. Also make
> >sure that the size of the packet is zero (DataUsed).
> >
> >2. immedeately before deleting stream pointer get associated IRP
> >KsStreamPointerGetIrp and set its
> >status to what you want it to be set to.
> >
> >Hope it helps,
> >– Max.
> >
> >
> >
> >— Hariharan Krishnamurthy wrote:
> > > Hi,
> > >
> > > I have implemented an AVStream mini-driver for streaming RGB data from a
> > > device. The streaming works fine with GraphEdit.exe, Windows Movie
> >Maker,
> > > Scanner & Camera Wizard and even with Windows Messenger.
> > >
> > > The problem i am facing is the time delay that Windows Messenger (WM)
> >takes
> > > to close the “Audio Tuning Wizard” while streaming RGB data from my
> >device.
> > > Using KsStudio.exe, i observed that WM is sending IRP_MJ_DEVICE_CONTROL
> > > (IOCTL_KS_READ_STREAM) periodically to read stream data from the capture
> >pin
> > > of my mini-driver. But while closing the “Audio Tuning Wizard” it takes
> > > nearly 10 seconds to issue a “pin close” to my capture pin.
> > >
> > > I also checked the behavior of msdv.sys (for a different device) through
> > > Windows Messenger. All the IOCTL_KS_READ_STREAM requests seem to be
> >failing
> > > with STATUS_CANCELLED when the wizard is closed. This means that even
> >my
> > > mini-driver also needs to return STATUS_CANCELLED somehow.
> > >
> > > My approach is as follows:
> > >
> > > 1) My Pin Process funtion returns STATUS_PENDING
> > > 2) Later when data is available (i mantain cloned stream pointers), i
> >call
> > > KsPinAttemptProcessing () to make the data available for processing to
> > > applications
> > > 3) When the filter graph is changing status to KSSTATE_STOP i delete all
> >the
> > > cloned pointers
> > >
> > > But, besides all these i need to cancel the IRPs associated with the
> >stream
> > > pointers. Can somebody give me some ideas on how to do is? Any
> > > ideas/pointers will be very helpful!
> > >
> > > Regards,
> > > Hari.
> > >
> > > _______________
> > > Cricket World Cup 2003- News, Views and Match Reports.
> > > http://server1.msn.co.in/msnspecials/worldcup03/
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@yahoo.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> >Do you Yahoo!?
> >Yahoo! Platinum - Watch CBS’ NCAA March Madness, live on your desktop!
> >http://platinum.yahoo.com
> >
> >
> >—
> >You are currently subscribed to ntdev as: xxxxx@hotmail.com
> >To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> _______________
> Cricket World Cup 2003 http://server1.msn.co.in/msnspecials/worldcup03/
> News, Views and Match Reports.
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@yahoo.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Do you Yahoo!?
Yahoo! Platinum - Watch CBS’ NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Hi,
Failing state transitions going from “active” states to “inactive” is not a
good idea. It
typically leaves the graph and/or filter and/or pin in question in some
sort of limbo state. Any
further attempts to break out of this state usually fail. Reconnecting pins
or rebuilding graph
solves the problem.
Your observation is very correct and that is why iam looking for a better
solution.
Regarding your problem of huge delay between state transition to stopped
and closing of the pin.
The only other thing I can think of is making sure that you reject any
stream pointers received by
the pin after it makes state transition from running or paused state.
Stream pointers are received before transitioning to pause state. The
sequence is as follows:
.
.
PinProcess () to submit buffers
change from run to pause
then pause to acquire
then acquire to stop
then close pin (takes 10 seconds at this point for close to be called)
I saw the cases when AVStream was sending stream pointers to the pin that
was in paused (when pin
descriptor set process-in-running-state-only flag) and even stopped state.
If you flush your queue
upon transition to stopped state and at the same time continue to accept
and queue new stream
pointers after the pin was stopped then those stream pointers will be stuck
in your queue forever.
In that case I would expect the application owning the graph to hung, but
maybe you have timeout
handlers set on stream pointers and you cancel them yourself in 10 seconds.
Just a guess.
I have no timeouts. It can be noted that this problem occurs with Windows
Messenger only and not with any other applications. It works fine with all
other applications like Windows Explorer, GraphEdit etc. With Windows
Messenger, there is a 10 second timer (i guess) before close is called.
Any answers/suggestions from Microsoft guys in the list will be very
helpful.
Hari.
– Max.
— Hariharan Krishnamurthy wrote:
> > Hi,
> >
> > If i set the IRP status to STATUS_CANCELLED as mentioned in your
> > approach[2], i was able to cancel the IRPs associated with the pending
> > buffers. This is what i think msdv.sys is also doing because i observed
>the
> > IRPs using KsStudio and the logs for MSDV and my driver look similar.
>But
> > Windows Messenger is still waiting for nearly 10 seconds for the buffers
>to
> > get complete.
> >
> > I have also observed that if i return STATUS_CANCELLED from the PinState
> > function while transitioning to KSSTATE_STOP then Windows Messenger does
>not
> > take so much time. But using this approach creates further
>complications,
> > my filter graph when run through Graphedit application does not work
> > correctly. It succeeds during the first run but after stopping the
>graph if
> > i run again then it fails.
> >
> > Any suggestions on this will be very helpful.
> >
> > Hari.
> >
> > >There are couple of things that I can think of. I have no idea whether
>or
> > >not it will be helpful,
> > >but this is what I would try.
> > >
> > >1. when deleting clone stream pointers make sure that they do not
>contain
> > >any flags, which may
> > >indicate that the stream pointer is of any use. In particular make sure
> > >that
> > >KSSTREAMPOINTER::KSSTREAM_HEADER::OptionsFlags does NOT have
> > >KSSTREAM_HEADER_OPTIONSF_DURATIONVALID and
> > >KSSTREAM_HEADER_OPTIONSF_TIMEVALID flags set. Also make
> > >sure that the size of the packet is zero (DataUsed).
> > >
> > >2. immedeately before deleting stream pointer get associated IRP
> > >KsStreamPointerGetIrp and set its
> > >status to what you want it to be set to.
> > >
> > >Hope it helps,
> > >– Max.
> > >
> > >
> > >
> > >— Hariharan Krishnamurthy wrote:
> > > > Hi,
> > > >
> > > > I have implemented an AVStream mini-driver for streaming RGB data
>from a
> > > > device. The streaming works fine with GraphEdit.exe, Windows Movie
> > >Maker,
> > > > Scanner & Camera Wizard and even with Windows Messenger.
> > > >
> > > > The problem i am facing is the time delay that Windows Messenger
>(WM)
> > >takes
> > > > to close the “Audio Tuning Wizard” while streaming RGB data from my
> > >device.
> > > > Using KsStudio.exe, i observed that WM is sending
>IRP_MJ_DEVICE_CONTROL
> > > > (IOCTL_KS_READ_STREAM) periodically to read stream data from the
>capture
> > >pin
> > > > of my mini-driver. But while closing the “Audio Tuning Wizard” it
>takes
> > > > nearly 10 seconds to issue a “pin close” to my capture pin.
> > > >
> > > > I also checked the behavior of msdv.sys (for a different device)
>through
> > > > Windows Messenger. All the IOCTL_KS_READ_STREAM requests seem to be
> > >failing
> > > > with STATUS_CANCELLED when the wizard is closed. This means that
>even
> > >my
> > > > mini-driver also needs to return STATUS_CANCELLED somehow.
> > > >
> > > > My approach is as follows:
> > > >
> > > > 1) My Pin Process funtion returns STATUS_PENDING
> > > > 2) Later when data is available (i mantain cloned stream pointers),
>i
> > >call
> > > > KsPinAttemptProcessing () to make the data available for processing
>to
> > > > applications
> > > > 3) When the filter graph is changing status to KSSTATE_STOP i delete
>all
> > >the
> > > > cloned pointers
> > > >
> > > > But, besides all these i need to cancel the IRPs associated with the
> > >stream
> > > > pointers. Can somebody give me some ideas on how to do is? Any
> > > > ideas/pointers will be very helpful!
> > > >
> > > > Regards,
> > > > Hari.
> > > >
> > > > _______________
> > > > Cricket World Cup 2003- News, Views and Match Reports.
> > > > http://server1.msn.co.in/msnspecials/worldcup03/
> > > >
> > > >
> > > >
> > > > —
> > > > You are currently subscribed to ntdev as: xxxxx@yahoo.com
> > > > To unsubscribe send a blank email to
>xxxxx@lists.osr.com
> > >
> > >
> > >
> > >Do you Yahoo!?
> > >Yahoo! Platinum - Watch CBS’ NCAA March Madness, live on your desktop!
> > >http://platinum.yahoo.com
> > >
> > >
> > >—
> > >You are currently subscribed to ntdev as: xxxxx@hotmail.com
> > >To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > _______________
> > Cricket World Cup 2003 http://server1.msn.co.in/msnspecials/worldcup03/
> > News, Views and Match Reports.
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@yahoo.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>Do you Yahoo!?
>Yahoo! Platinum - Watch CBS’ NCAA March Madness, live on your desktop!
>http://platinum.yahoo.com
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
_________________________________________________________________
Cricket - World Cup 2003 http://server1.msn.co.in/msnspecials/worldcup03/
News, Views and Match Reports.