StreamClassCallAtNewPriority, Problem #2.

Hi folks,

Looks like it’s a case of “out of the frying pan and into the fire!”. I now have
my own worker thread in my driver, which takes the place of
StreamClassCallAtNewPriority. I then fairly thoroughly tested it, including some
slight “abuse” just to check a few corner cases in my code. I’m not actually
posting work items, since I never need to queue more than one thing at once per
stream, I’m just setting some flags, giving it a function pointer, and setting a
Synchronization event. All works great.

But now I have a new (and bizzare) problem. In a rendering minidriver, we get to
the end of the stream, do a bit of handshaking with our hardware, and use
“StreamClassStreamNotification” to indicate that we’ve processed the end of the
stream.

When it works, the graph then transitions back down to the stop state, and the
user application then starts the whole graph again (it’s set to loop a media
clip).

When it fails, we send the notification, it disappears into a black hole, and
the graph doesn’t stop (and more importantly for me, restart & loop).

The behaviour seems to be strongly timing dependent. If I boot the machine with
the /debug switch, whether I have the debugger connected or not, it almost
always works. If I just boot with no special switches, it almost always fails.

And the wierdest thing of all is that if the graph has got “stuck”, I can leave
it there for quite some time, and it’ll stay as it is, but a mouse click on the
user mode application magically wakes it up again, and the notification gets
delivered!?!?!

yours (very confused)

Martin Harvey.

Reply Separator
Subject: Re:(ntdev) RE: (ntdev) Workaround for StreamClassCallAtNewPr
Author: M Harvey
Date: 24/11/2004 09:59

Reply Separator
Author: “Max Paklin” smtp:xxxxx

>As a workaround you can start a worker thread and post to it what you
>would normally post to a work item scheduled with
>StreamClassCallAtNewPriority.

Thanks for the advice, this is what I’m doing. I reckon a library with a worker
thread, and a queue per stream, with the worker thread processing the streams in
a round-robin fashion should do the job nicely.

Best of all, it means that I can actually see what’s going on, instead of a
notification disappearing into a black hole and never coming back!

MH.

This email and any attachments is confidential, may be legally privileged and is
intended for the use of the addressee only. If you are not the intended
recipient, please note that any use, disclosure, printing or copying of this
email is strictly prohibited and may be unlawful. If received in error, please
delete this email and any attachments and confirm this to the sender.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

This email and any attachments is confidential, may be legally privileged and is intended for the use of the addressee only. If you are not the intended recipient, please note that any use, disclosure, printing or copying of this email is strictly prohibited and may be unlawful. If received in error, please delete this email and any attachments and confirm this to the sender.</smtp:xxxxx>

Just a guess but can you make sure that you aren’t blocking in your message dispatching loop? The
fact that the application wakes up upon the mouse click definitely looks like it was waiting for a
message to arrive and then upon arrival you checked to see if there is a DShow/KS event pending.

– Max.


From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of M
Harvey
Sent: Thursday, November 25, 2004 9:15 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] StreamClassCallAtNewPriority, Problem #2.

Hi folks,

Looks like it’s a case of “out of the frying pan and into the fire!”. I now have
my own worker thread in my driver, which takes the place of
StreamClassCallAtNewPriority. I then fairly thoroughly tested it, including some
slight “abuse” just to check a few corner cases in my code. I’m not actually
posting work items, since I never need to queue more than one thing at once per
stream, I’m just setting some flags, giving it a function pointer, and setting a
Synchronization event. All works great.

But now I have a new (and bizzare) problem. In a rendering minidriver, we get to
the end of the stream, do a bit of handshaking with our hardware, and use
“StreamClassStreamNotification” to indicate that we’ve processed the end of the
stream.

When it works, the graph then transitions back down to the stop state, and the
user application then starts the whole graph again (it’s set to loop a media
clip).

When it fails, we send the notification, it disappears into a black hole, and
the graph doesn’t stop (and more importantly for me, restart & loop).

The behaviour seems to be strongly timing dependent. If I boot the machine with
the /debug switch, whether I have the debugger connected or not, it almost
always works. If I just boot with no special switches, it almost always fails.

And the wierdest thing of all is that if the graph has got “stuck”, I can leave
it there for quite some time, and it’ll stay as it is, but a mouse click on the
user mode application magically wakes it up again, and the notification gets
delivered!?!?!

yours (very confused)

Martin Harvey.

Reply Separator
Subject: Re:(ntdev) RE: (ntdev) Workaround for StreamClassCallAtNewPr
Author: M Harvey
Date: 24/11/2004 09:59

Reply Separator
Author: “Max Paklin” smtp:xxxxx

>As a workaround you can start a worker thread and post to it what you
>would normally post to a work item scheduled with
>StreamClassCallAtNewPriority.

Thanks for the advice, this is what I’m doing. I reckon a library with a worker
thread, and a queue per stream, with the worker thread processing the streams in
a round-robin fashion should do the job nicely.

Best of all, it means that I can actually see what’s going on, instead of a
notification disappearing into a black hole and never coming back!

MH.

This email and any attachments is confidential, may be legally privileged and is
intended for the use of the addressee only. If you are not the intended
recipient, please note that any use, disclosure, printing or copying of this
email is strictly prohibited and may be unlawful. If received in error, please
delete this email and any attachments and confirm this to the sender.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

This email and any attachments is confidential, may be legally privileged and is intended for the
use of the addressee only. If you are not the intended recipient, please note that any use,
disclosure, printing or copying of this email is strictly prohibited and may be unlawful. If
received in error, please delete this email and any attachments and confirm this to the sender.

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</smtp:xxxxx>