If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
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 |
Ads |
#2
|
|||
|
|||
DDERR_WASSTILLDRAWING always for AVI and DVD on old ATI Radeon
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 |
#3
|
|||
|
|||
DDERR_WASSTILLDRAWING always for AVI and DVD on old ATI Radeon
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 |
Thread Tools | |
Display Modes | |
|
|