Can someone help? My Firewire port (Texas Instruments OHCI Compliant IEEE 1394 Host Controller) is on the same IRQ as my crappy onboard sound. I am PRETTY sure this may be why I am dropping frames when capturing to ANY program using my DV cam. Any way around this?
I hate to see you go off into the weeds on this. The IRQ is almost certainly NOT your problem. My computer shares IRQ 17 between my Firewire card and my SoundBlaster sound card. Not only can I capture without dropping frames, I can do pretty much anything I want (surf the Internet, write letters, etc.) while capturing. Of course, the fact that it works on my system is absolutely no help to you. I only mention it to illustrate that modern computers running XP seldom have IRQ conflicts, even when the IRQ is shared (it was a BIG problem on older designs). If there is a conflict, you will see a warning message when you go to the Device Manager in XP.
Here are some more likely culprits.
1. DMA. Must be enabled. Check the Device Manager. If it is not enabled, you WILL drop frames. Guaranteed.
To check Device Manager: (My Computer -> View System Information -> Hardware tab -> Device Manager -> IDE Controller -> Primary IDE Channel -> Advanced Settings). Adobe has more specific information on how to do this, and how it relates to dropped frames:
2. Background processes. This is different than background applications (you already said you have no other apps running). Press Ctrl-Alt-Del and click on the Process tab. Click on the CPU heading to sort by CPU usage. Capture some video. See if any process bounces to the top for a few seconds. Use MSCONFIG to temporarily disable any process that you suspect might be causing a problem (don't disable the SYSTEM processes). You have to re-boot after disabling a process using MSCONFIG. Don't forget to re-enable it when you are finished (unless of course it is the cause of your problem). If you have an HP printer with a built-in card reader, there is a really nasty frame-dropping process called HPHA1MON. This definitely must be killed.
3. Capture to a different physical hard disk than the one used for your program files. This should not be necessary for a fast, new system, but it can't hurt.
4. Search this forum for "dropped frames." There was a long thread about two months ago ... ah, here it is ...
Glancing over this thread, it had many of the same suggestions given in this thread. In the end, no luck. Interesting, though. This guy reported (towards the end of the thread) 36 dropped frames. Hmm.
Also, check this out. Sounds almost identical to your problem (reported dropping exactly 36 frames -- Hmmm again):
This responder to this post suggested turning off MS Office Find Fast and also disabling the MS index service (uncheck "Allow Index Service").
I definitely agree. The Index Service is EVIL. Really kills performance.
My bet is on background processes. The solution is MSCONFIG. It is simple and safe to use. Use it to kill background processes until your problem clears up.
If you want to "cut to the chase" quickly, use MSCONFIG to disable ALL processes (using the "instructions" above) that have your computer's name after them. Reboot. Try a capture. Let us know what happens.
One cause of dropped frames that is often overlooked is your power saving features. If your screen saver, monitor or network card idle, or other scheduled event kicks in after you start capturing, it can indeed cause a hiccup at a repeatable interval and duration.
The simple test to see if the IRQ sharing you noted is part of the problem is to disable the onboard sound in BIOS, including any gameport and MIDI ports. Then see if you have dropped frames.
John is correct, the DMA setting in XP (which is a lot harder to find than it used to be) is more likely to cause an issue than IRQ sharing, although moving things around to minimize sharing certainly does no harm.
However, I have never liked or had good luck with those AC97 sound chips, and have always ended up disabling them and installing a sound card.
With 1394 cards regularly on sale for $20, it would be prudent to try a different one. The TI chip is one of the most reliable in my understanding, but some of the earliest ones had problems that apparently could not be duplicated from card to card.
I appreciate all your help, John. I tried every thing you mentioned and nothing was fixed, however I did the whole checking background processes thing and noticed my entire CPU usage % dropped from around 40% to 1% at the exact time the dropped frame thing occurs. Does this bring up any more ideas? Thank you.
So do I understand that you have used MSCONFIG to eliminate ALL background processes, other than those listed under User Name "SYSTEM"?And, after you did this, you first re-booted and then immediately tried a capture, and that capture still failed? Also, when you checked on the DMA setting, what exactly did the Device Manger report? Do you have more than one hard disk? Did it report the same thing for each one? Have you definitely turned off the indexing service?
Another trick with the Task Manager (it's what comes up when you press Ctrl-Alt-Del), is to click on View, then Select Columns. Click on "CPU Time", "I/O Read", and "I/O Writes." Click on OK. Then, click on the "CPU Time" heading to sort by CPU time. Start a capture and let it run for awhile. Keep track of which processes have a non-zero time. This is best done immediately after a re-boot so all processes have zero, or near-zero values to start with. You may be able to find one or more processes that are taking extra time.
I just tried this myself. I re-booted, then brought up Task Manager, and followed my instructions above. I captured about a minute of video using Vegas Capture (4.0). When I was finished, I only had a handfull of processes that had consumed more than zero time. Here they are:
svchost.exe 0:00:01
vegas40.exe 0:00:01
winlogon.exe 0:00:01
csrss.exe 0:00:01
services.exe 0:00:01
explorer.exe 0:00:03
taskmgr.exe 0:00:04
System 0:00:09
vidcap40.exe 0:02:36
system idle process 0:02:51
This represent almost exactly one third of all the processes listed. The others all showed values of zero.