View Full Version : Onboard sound my problem?
somail
25th February 2005, 01:25
I have been having issues with dropped frames and A/V sync.
Hardware:
Motherboard M7NCG 400
AMD XP @ 2.0 Ghz
AIW VE (PCI)
80GB 7200 2mb HDD
256 RAM @ 200mhz edit: actually 512
I have captured using all versions of Vdub including v1.6.4 and sync versions. On average I will drop around 300-700 frames an hour using PicVideo's MJPEG codec. CPU usage will never go above 15%. The VT adjust number in Vdub will sometimes endup at numbers in the tens of thousands. I do not know what a normal system will produce, but I'm assuming that should not happen. With audio not being captured,I average around 14 frames dropped an hour. I assume this is normal, even though I wish I could get it lower. During playback in media player I will also get hicups during playback in which my system will temporary freeze and upon unfreezing, audio sync will be way off. (Reclock seems to do nothing)
The onboard chip is a Realtek ALC650/655 . I have not found any issues with this chipset on any forums/google, but this is my second M7NCG and both have had the exact same problems. I have performed numerous formats and driver combos.
The real questions:
1. Does my diagnosis seem correct to you?
2. Are there any tests I can run to see if I'm right?
3. I will probably get a new sound card this weekend, so I will need some recomendations. The system is going into a custom HTPC case, so audigys and the like are out of the question. I just want a small 2 channel card that has a stable clock rate.
thanks for reading,
somail
Video Dude
25th February 2005, 04:51
On-board sound can cause drop frames if it relies on the CPU for processing because it has the potential to max out the CPU while capturing. But since you say CPU usage is 15% this may not be the problem.
You might get better results if you bumped your RAM up to 512 MB.
Also, much better results can be expected if you capture to a second hard drive and not the same drive you have Windows installed. The reason is if Windows does a background write or has to use the swap file, frames may drop as a result.
Did you try a different codec to see if you still drop frames?
You don't say what resolution or audio codec you are using. So I can't say if your dropped frames is normal for your system specs.
somail
25th February 2005, 06:03
thanks for the reply.
I actually have 512 of RAM. Sorry about that.
Audio is uncompressed PCM. Resolution is 640x480.
Other codecs give me the same result, but picvideo's codec is the only one that I can capture at 640x480 and not drop frames every other second. It also seems to minimize sync loss for some reason. I havn't tried capturing at a higher res since I replaced the HDD, so I'll see if I can go higher. I originally had an old 5400RPM drive. I should probably mention that the amount of frames being dopped is the same amount for any resolution under 640x480.
I should also mention that my onboard sound shares an IRQ with my onboard USB, but I do not really think that is causing me problems.
Never thought about windows needing to use the HDD while I'm capturing. I'm not up for buying a second HDD right now. First I just want to get to make sure I solve the big problems first. :)
somail
26th February 2005, 10:22
Went out and got a $15 soundcard. Seems to be alittle more stable. Vdub still needs to adjust latency, but never anymore than 30ms. Much better than 25000 ms.
Still dropping about 20-30 frames a hour, and I can't capture above 640x480 without dropping about 2 frames everyother second. CPU usage still stays in the teens. Besides capturing to a non OS drive, is there anything else I should take a look at.
thanks
2ZOD.COM
7th March 2005, 17:17
What other codecs have you tried to capture with? If you haven't triedn HuffyUV I would recommend that. It's lossless too, so you should get a little better overall quality than with mjpeg.
Sometimes it's just the source of the video that will give problems. I've captured a few hundred tapes and sometimes I can't help but drop a few frames.
What is your source video? Have you tried hooking it up to a stable source such as a DVD player just to test it out?
somail
7th March 2005, 22:36
I actually just switch to Huffyuv a few days ago since picvideo wouldn't capture to YUY2. I just did a capture at 720x480 and dropped about 50 frames an hour with Huffy which isn't too bad. I havn't tried changing sources, but I can try that later today and see what happens. Disabling sound capture really helps, so I tried switching to virtualvcr and virtualdub sync to see if the resample options would help. With virtual VCR I drop frames like crazy and Vdub sync can't even find my sound card. I just found out last night that I can capture mpeg2 @ 720x480 without dropping anyframes and I can run virtualdub's bench mark for hours and not drop a single frame. This leads me to think that the only way to fix this is through software, since the HDD seems to be fine, and I have already replaced the soundcard once. Although fry's had a deal on a 200GB HDD for $69 this past week, so I may jump on that when it happens again.
Nematocyst
9th March 2005, 00:57
I just found out last night that I can capture mpeg2 @ 720x480 without dropping anyframes and I can run virtualdub's bench mark for hours and not drop a single frame.
This plus the fact you aren't taxing your CPU leads me to believe the HD isn't able to keep up. It may not be the HD, but the interface. Make sure you have the latest chipset drivers for your MB, and that DMA is enabled.
That your problems increase when storing uncompressed audio also lends credence to this theory. See if compressing the audio results in fewer dropped frames.
jggimi
9th March 2005, 15:32
...leads me to believe the HD isn't able to keep up....
An IDE bus runs at the speed of the slowest device. If there's a CD or DVD drive on the same bus, this could be the limiting factor.
Boulder
9th March 2005, 15:45
An IDE bus runs at the speed of the slowest device. If there's a CD or DVD drive on the same bus, this could be the limiting factor.
Doesn't apply anymore, it's been a while from that restriction and based on quick Googling it only happens when you use PIO modes. Problems might occur if the CD or DVD drive is accessed when capturing though.
somail
9th March 2005, 19:42
Thanks for the replys. The motherboard is a biostar M7NCG 400 (Nforce 2). Anyways I have all updated drivers installed, except for Nvidia's IDE drivers. The reason bring is that they simply do not work and any performance gain is non-existent. But UDMA is on, I double check once a week, since windows loves to enable PIO when it reads burned DVD's. Also the HDD and DVDrom are on different controllers. Last night I ordered a Seagate 200gb 7200 drive so hopefully in a week I will know if my current HDD is to blame. I'll try a compressed audio capture at 720x480 and see what happens.
thanks
Nematocyst
9th March 2005, 21:55
You should be using the latest nvidia IDE drivers. I bet this is the bulk of your problem if not the entire problem.
If they do not work, it's best to figure out why and correct it. Although I don't have the same MB as you, mine is the same chipset (not quite, but same southbridge anyway), so I can tell you the driver works fine. Perhaps you aren't running the latest service pack? I dunno if that matters-- according to nvidia, you need SP1 for the USB2.0 drivers and there is no mention of any specific IDE requirements. I am running the accelerated driver which you are prompted about during the install.
I'm not trying to bum you out, just to illustrate what your system should be capable of-- my hardware is very similar to yours, and I routinely capture to PicVideo at 720x480 w/ uncompressed audio and 0 dropped frames for hours, even while browsing or, get this, playing starcraft. I'm not kidding. I use VirtualVCR, but I doubt that is relevant.
somail
10th March 2005, 00:56
Tried the IDE drivers again, and still no go. The main problem is that the drivers fail to run my drives in UDMA mode. They will say UDMA enabled and as the current mode; problem is that the drives are really in PIO mode. I have confirmed this many times with many different programs.
Tried compressing audio, but I dropped alot of frames pretty quickly about 300 in the first few minutes. CPU usage was around 25%-30%, while I was using Lame @ 128bit.
Nematocyst
10th March 2005, 01:16
Hm. Maybe we need to back up then. Are you using the 80 pin shielded cable with the blue end attached to your drive? It's possible to achieve UDMA without this cable, but not the advanced modes. (eg, UDMA mode 2 which CD/DVD drives can get)
edit:
er, you can't get modes 4, 5 or 6 unless using this cable
Also, examining a spare cable, I see blue goes into the MB. You want to use the opposite end (not the grey one) into your HD.
somail
10th March 2005, 02:39
hmmm... Thats the first I've ever heard about cables effecting UDMA modes. But it shouldn't matter since when I use the stock microsoft IDE drivers I am in UDMA 5.
Nematocyst
10th March 2005, 19:46
Yes, the cable does matter. If you bought a retail drive and used the cable that came with it, then you are probably fine. But people sometimes buy an OEM (bare) drive and then use a spare CDROM/DVD IDE cable. That'll kill the HD performance.
If you are really in UDMA-5, then it would seem the HD isn't the problem. I doubt the native MS drivers would incorrectly report the mode either. However I still have trouble dismissing the HD as the culprit because the Nvidia drivers aren't working right, and because the the problem is obviously not due to overloading the CPU.
I actually just switch to Huffyuv a few days ago since picvideo wouldn't capture to YUY2. I just did a capture at 720x480 and dropped about 50 frames an hour with Huffy which isn't too bad.
This is contrary to my theory that it's the HD since Huffyuv needs more storage than Picvideo.
I should probably mention that the amount of frames being dopped is the same amount for any resolution under 640x480.
This also indicates it isn't the HD.
edit: Unless you were capturing uncompressed audio and that was enough to cause the problem by itself.
I just found out last night that I can capture mpeg2 @ 720x480 without dropping anyframes
This is pretty strong evidence that it IS the HD, since those files need less storage than huffyuv or Picvideo.
This problem has me stumped. Hopefully your new HD will fix it. As others have noted, having a dedicated capture disk should bump up performance.
somail
14th March 2005, 05:00
Okay it was a very productive weekend. After a bunch of messing around I finally got virtualVcr working. With the new hardrive and virtualVcr I drop 4 frames in two hours. In virtualdub I drop around 45 frames with the new drive, so I think virtualdub is just can't keep up with my unstable audio clock.
thanks for all your help guys.
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.