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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>
|