DDERR_WASSTILLDRAWING always for AVI and DVD on old ATI Radeon

Hello,

I have a quite strange DirectShow/DirectDraw/ATI hardware issue on one
machine that's completely elluding me.

Any program playing video has one or both of the following issues:

1. Freezing to a constant frame unless I move the window and somehow force
the window to refresh this way.
2. Completely freezing the machine when closing.
3. Sometimes, the process will go up to 50 % CPU usage. This is a dual CPU
system, so it's in fact hogging one CPU.

Sometimes I can't even get it to play by moving the window. This happens in
RealPlayer, PowerDVD, WMP 9 (and, later, 10) and just about any application
that wants to play video on my main card, an ATI Radeon All-in-Wonder 7500.
I know it's quite an old card, but it's worked fine before.

I can't exactly pinpoint when this first happened, it's a machine mainly
used for development and I didn't have time to watch any movies for a long
time on it. When I tried to, I discovered this issue.

I've also tested in the very simple "graph edit" program in the DirectX SDK
for DirectShow. It seems this is directly related to the Video Renderer
filter. (No surprise there.)

When prying into this with a debugger in the Graph edit configuration, I
found out that there is a very tight loop in quartz.dll that will repeatedly
try to blit a video frame with DdBlt if it gets DDERR_WASSTILLDRAWING. The
problem is that the card seems to lock into this status without ever leaving
it. If I patch out the comparisons to DDERR_WASSTILLDRAWING in the assembly
code on the fly with the debugger, I'm able to get the sound to play and
bring down CPU usage, but I basically get performance like bullet number 1
above (frames not updating normally).

For one thing, the code in quartz.dll is inefficient in this case by
hammering new requests. Some other loops that I also found did at least call
Sleep between their requests. (For example when locking surfaces.)

I've tried the most obvious things, like disabling and taking out my second
video card (an even older non-ATI PCI card). That card is able to play video
properly, if the ATI card is disabled, but the performance of the bus is not
sufficient to play fullscreen VGA video. I can also disable all DirectDraw
acceleration of the ATI card, but that will naturally also be quite
devastating to the performance.

General DirectDraw tests in for example dxdiag works fine. This issue first
appeared while I was still runing SP1 on the box, but I've later upgraded to
SP2 and WMP 10 without any noticeable difference. I've tried the complete
uninstall for Catalyst drivers provided by ATI.

I repeat that this has worked before with basically the same system. One
thing that has changed since the last time I was sure to play video
correctly is a memory replacement/upgrade. A 256 MB module went bad after
two years of use, so I replaced it with a new quality one. I tested the new
one with the same Microsoft memory test boot CD that proved the failure of
the first one, so I'm quite sure this is not a memory issue.

The fact that the driver is not "aware" that the frame has actually been
drawn could indicate some kind of interrupt handling problem, but I don't
know what I could have done to make it fail.

Have anyone experienced something similar to this? I'm thinking about if for
example some secondary DirectShow filter is interfering. As DirectDraw in
general is working quite fine, I was quite surprised to see that the actual
blitting of the frame seems to be the center of the problem.

Regards,
Carl

Update if anyone is interested:

I switched places of a few more PCI cards and that got rid of this problem.
It's still impossible for me to capture for any significant time, the
process will stall in a similar way that the DVD player did before. As there
is really no IRQ sharing going on now, I'm out of ideas. If I find out
anything I believe can be of interest to others, I'll post it here.

/Carl


"Carl Nettelblad" wrote in message
...
Hello,

I have a quite strange DirectShow/DirectDraw/ATI hardware issue on one
machine that's completely elluding me.

Any program playing video has one or both of the following issues:

1. Freezing to a constant frame unless I move the window and somehow force
the window to refresh this way.
2. Completely freezing the machine when closing.
3. Sometimes, the process will go up to 50 % CPU usage. This is a dual CPU
system, so it's in fact hogging one CPU.

Sometimes I can't even get it to play by moving the window. This happens
in RealPlayer, PowerDVD, WMP 9 (and, later, 10) and just about any
application that wants to play video on my main card, an ATI Radeon
All-in-Wonder 7500. I know it's quite an old card, but it's worked fine
before.

I can't exactly pinpoint when this first happened, it's a machine mainly
used for development and I didn't have time to watch any movies for a long
time on it. When I tried to, I discovered this issue.

I've also tested in the very simple "graph edit" program in the DirectX
SDK for DirectShow. It seems this is directly related to the Video
Renderer filter. (No surprise there.)

When prying into this with a debugger in the Graph edit configuration, I
found out that there is a very tight loop in quartz.dll that will
repeatedly try to blit a video frame with DdBlt if it gets
DDERR_WASSTILLDRAWING. The problem is that the card seems to lock into
this status without ever leaving it. If I patch out the comparisons to
DDERR_WASSTILLDRAWING in the assembly code on the fly with the debugger,
I'm able to get the sound to play and bring down CPU usage, but I
basically get performance like bullet number 1 above (frames not updating
normally).

For one thing, the code in quartz.dll is inefficient in this case by
hammering new requests. Some other loops that I also found did at least
call Sleep between their requests. (For example when locking surfaces.)

I've tried the most obvious things, like disabling and taking out my
second video card (an even older non-ATI PCI card). That card is able to
play video properly, if the ATI card is disabled, but the performance of
the bus is not sufficient to play fullscreen VGA video. I can also disable
all DirectDraw acceleration of the ATI card, but that will naturally also
be quite devastating to the performance.

General DirectDraw tests in for example dxdiag works fine. This issue
first appeared while I was still runing SP1 on the box, but I've later
upgraded to SP2 and WMP 10 without any noticeable difference. I've tried
the complete uninstall for Catalyst drivers provided by ATI.

I repeat that this has worked before with basically the same system. One
thing that has changed since the last time I was sure to play video
correctly is a memory replacement/upgrade. A 256 MB module went bad after
two years of use, so I replaced it with a new quality one. I tested the
new one with the same Microsoft memory test boot CD that proved the
failure of the first one, so I'm quite sure this is not a memory issue.

The fact that the driver is not "aware" that the frame has actually been
drawn could indicate some kind of interrupt handling problem, but I don't
know what I could have done to make it fail.

Have anyone experienced something similar to this? I'm thinking about if
for example some secondary DirectShow filter is interfering. As DirectDraw
in general is working quite fine, I was quite surprised to see that the
actual blitting of the frame seems to be the center of the problem.

Regards,
Carl

I solved most of my problems by moving a PCI card and then getting the
interrupt affinity tool from the Windows 2003 Resource Kit (you can find it
on the MS website). It actually works in anything from Windows 2000 and up
and lets you say that most of the handling of some device should be locked
to a certain CPU. This is, in reality, a workaround for some thread
synchronization issue showing up with multiple CPUs. My guess is that it
only makes the problem unlikely enough to make things work properly most of
the time, but that is good enough for me.

Windows Media Encoder is still not working properly with the card, but most
others capture applications are.

/Carl