All-in-Wonder 9800 Pro + Audigy 2 ZS... synch/drop problems

[Brad]

I just built a computer for the first time, and it's giving me synch problems when capturing. I always capture as 640x480 29.97 fps Huffyuv-encoded YUY2 AVI w/uncompressed CD quality sound, and my preferred capture program is AVI_IO. This works just fine on my current computer (an older Compaq w/1.2 GHz Celeron, 2x256MB RAM, and using my All-in-Wonder 128 Pro along with the motherboard's Intel sound), resulting in 2-3 frame drops for 30 minute captures, which I'm just fine with.

However, whenever I try to capture with my new computer using an All-in-Wonder 9800 Pro with the same settings in AVI_IO, I'm left with 15-20 frame drops for 30 minutes, which I find unacceptable. I know for sure that the problem lies in the sound card, as when I choose to capture without sound, I get 0 drops (and the processor usage is around 18-22%). AVI_IO is dropping frames in order to synch the video back with the audio (and the synch is fine in the captured files). Initially I had tried capturing with the onboard sound (some Realtek chip), but I sprung for the Sound Blaster Audigy 2 ZS thinking that it would solve the problem. No go, sadly. The frame drop count is roughly the same. I properly disabled the onboard sound in the BIOS, and even reformatted to get rid of the Realtek AC'97 codec/driver before installing the Creative one.

I tried capturing in VirtualDub instead, and it reports negative VT adjust values after about 5 minutes of capping (which is about the time that AVI_IO starts dropping). I tried Virtual VCR, with its audio resampling. It reports a delta of 0.19... for both the onboard and Audigy audio. After capturing for 30 minutes, 0 frames drop, but upon checking the captured file, the audio loses synch after a minute or two and also Virtual VCR's resampling causes the audio to have a far lower than normal pitch.

I've tried using the automatically-installed WDM driver for the AIW, and the newest one off of ATI's site. For the onboard audio, I've tried using the Realtek driver off of the motherboard's CD, and the newest one off of MSI's site. For the Audigy 2 ZS card, I've tried using the Creative driver off of the CD (with and without the additional software package), and the newest one off of Creative's site. I also tried the "kX" freeware driver project. I've tried moving the Audigy card from the 5th PCI slot to the 3rd one (my ATA133 controller card sits in the 4th). Nothing changes in the captures in either AVI_IO, VirtualDub, or Virtual VCR between any of these combinations.

I'm at a loss now for what I can do to try and fix this, so I come here seeking any assistance you may be able to offer... I apologize for the long post, but I'm trying not to leave anything relevant out. Finally, here are the specs of my new machine:

CPU: AMD Athlon64 3200+ (Newcastle)
Motherboard: MSI K8N Neo Platinum (nVidia nForce3 250Gb)
RAM: 2x512MB Samsung PC3200
PSU: Ultra X-Connect 500W
HDs: Western Digital ATA100 7200RPM 250GB w/8MB cache (system), Western Digital ATA100 7200RPM 120GB w/8MB cache (capping), Maxtor ATA133 7200 RPM 80GB w/2MB cache (extra storage)

[thecoalman]

Try the capture guide for ATI here: www.digitalfaq.com

That's Lordsmurf's site, he's the resident ATI expert. I will tell you the first thing he's going to say is use MMC for capturing.

[Ron B]

Hello-I have the same video and sound card as you do, however, I have an Intel mobo and CPU. I use it with VirtualDub and huffyuv without any dropped frames. I suggest you check your IRQs and IRQ sharing. Get the video card and sound card on their own IRQ and don't share either of these devices with your hard drive controllers.

[Soopafresh]

EXCELLENT description of your problem and the steps you've taken already to try and solve it.

Move your Audigy Card to a different PCI slot.

Turn down hardware acceleration on your video card in "Display Properties".


Also, have you installed this ? AMD recommends it.

http://www.amd.com/us-en/Processors/TechnicalResources/0%2C%2C30_182_871_9706%2C00.html

Also, look at the KxProject FAQ for better audio drivers for your Audigy Card.

http://kxproject.lugosoft.com/faq.php#Q1

[Brad]

@thecoalman:

First of all, YUCK, proprietary bundled junk! Second, the captured files from MMC gradually drift out of synch.

@Ron B:

I took the Audigy 2 ZS card out again and won't have a chance to put it back in and try that until tonight, but I did check it out with the onboard sound enabled again. The ATI card has the IRQ named PCI 16 to itself, but the "Realtek AC'97 Codec" shared PCI 23 with one of the two onboard USB controllers. My keyboard was the only device using it, so I just stuck it into a lower USB connector and Device Manager reported that it was on the other USB controller then. So I disabled the USB controller not in use and the audio then had 23 to itself. I tried capping again and there was no improvement in any of the programs. Same delta in VVCR, same time for VT adjust to start going up (though it went to positive values; I think I was wrong before and it always went positive and not negative), and same drop frame time in AVI_IO.

Even worse, now whenever I finish capping something and go to capture in another program, the computer totally crashes! No response from anything, except the mouse does move until I try to click something and then it freezes entirely, and SOMETIMES the power button shuts down Windows with a single tap instead of having to hold it down and shutting down the whole comp. The screen even goes black and the power light on the monitor flashes (the way it does when the computer is turned off but not the monitor). One time I saw an error flash up briefly about some ati DLL or something causing an error... Re-enabling the USB controller didn't fix this, so hopefully reformatting will.

But one last thing, did you mean get each of the AIW and the sound card on their own IRQ (like one on 16 and the other on 23, as I did), or did you mean get them both on ONE (like both on 16).

@Soopafresh:

Well as I said, I did try moving from 5 to 3 with no difference, but I'll try sticking it in the other 3 tonight.

Erm, sorry, but how is turning down hardware acceleration on the VIDEO card going to help in this instance?

I haven't installed the processor driver there, but I did install MSI's Core Center utility, which seemingly does the same thing, from the description there.

As I did note in my original post, I tried the kX project drivers with no difference (plus I dislike the fact that you HAVE to use their menu to set the recording source - the only one displayed in Windows Volume Control under that driver is "Recording Level").

[Brad]

Oh, and there are 0 drops with MMC, but the video does go out of synch.

[lordsmurf]

@thecoalman:
First of all, YUCK, proprietary bundled junk! Second, the captured files from MMC gradually drift out of synch.

I'm afraid you don't know what you're talking about.
This is not "bundled junk".
Pinnacle, Roxio, Nero ... that's bundled junk.

ATI MMC is a capture software written specifically to use the technology found on the ATI AIW cards. It is VERY WELL WRITTEN too. The only flaw with it are the presets are stupid. It is obvious video pros did not create them. Visit www.digitalFAQ.com and read the ATI guides for how to set your own high quality templates.

Audio sync can be caused by many things. Also understand all versions of HuffYUV are different, may not work on all systems. Uncompressed captures are best, MJPEG is an alternate "lossless" compression capture method too. A working HuffYUV codec is provided on the ATI guides.

Audigy cards are known to cause sync issues. Those cards really suck for video capture. Cheapo audio cards (AC'97, etc) ... same thing. This is probably where your issues lie.

[Brad]

Well, MMC may be fine for you, but I've really never liked it. At any rate, should I just try to take the Audigy back and get the Sound Blaster Live! 24-bit then?

[thecoalman]

@thecoalman:

First of all, YUCK, proprietary bundled junk! Second, the captured files from MMC gradually drift out of synch.

Is that not your issue now with other capture programs too? :P

Well, MMC may be fine for you, but I've really never liked it. At any rate, should I just try to take the Audigy back and get the Sound Blaster Live! 24-bit then?

FYI had the same card and a Audigy2, the internal audio test in MMC always reported slight sync problem. I never had a reason to figure out how to fix because I got rid of it for other reasons. Anyhow Good Luck!

[lordsmurf]

Well, MMC may be fine for you, but I've really never liked it. At any rate, should I just try to take the Audigy back and get the Sound Blaster Live! 24-bit then?

I would try to exchange cards, yes.

[Brad]

@thecoalman:

First of all, YUCK, proprietary bundled junk! Second, the captured files from MMC gradually drift out of synch.

Is that not your issue now with other capture programs too?

Yes. I was just saying there's no difference using that instead of VDub or something.

I would try to exchange cards, yes.

Alright, thanks. We'll see how that goes.

[Ron B]

But one last thing, did you mean get each of the AIW and the sound card on their own IRQ (like one on 16 and the other on 23, as I did), or did you mean get them both on ONE (like both on 16).

Ideally, you'd want the video card on it's own IRQ. If you can avoid IRQ sharing with the hard drive controllers and your sound card(or video card for sure), that should help your computer's performance. The idea being that while your video card, sound card and hard drives are working capturing video, they are not sharing the same computer resources. If you changed the sound card from one PCI slot to another, you should have noticed a change in IRQ assignments. If changing the sound card from one PCI slot to another causes your computer to crash, you have other issues.
There was a similar issue regarding the Audigy and IRQ sharing on my Intel mobo, switching the PCI slots did the trick.
As I mentioned earlier, I have no audio sync issues with the Audigy 2 ZS using VirtualDub and huffyuv and the firewire works fine as well. That would lead me to believe you either have a defective sound card, or there is an issue specific to your particular motherboard regarding the Audigy 2 ZS. Of course this is assuming when you built your computer you correctly installed the most current board and chipset drivers.
Good luck with your problem. I'm sure you'll figure it out eventually, that's what moves you on from "first time computer builder".

[mpack]

MJPEG is an alternate "lossless" compression capture method too.

Eh? In what sense is MJPEG a lossless compression method?

IMHO: Uncompressed is not best. All else being equal you want the codec that gives the best compression. That makes Huffyuv best because, being lossless, its output is equal in quality to an uncompressed AVI, but only takes up between a half or third of the space. The reduced bandwidth requirement also means fewer dropped frames etc.

[lordsmurf]

MJPEG is an alternate "lossless" compression capture method too.

Eh? In what sense is MJPEG a lossless compression method?

.

In about the same sense as HuffyUV is "lossless".

[boggen]

with your statment of you get lost in both onboard sound and with the add in sound card, the problem is not with either, but system settings and drivers.

with statment of having a nvidia built on video card on the motherboard and adding a all and wonder to the system if ya not having conflicts there.

perhaps reading it wrong
Motherboard: MSI K8N Neo Platinum (nVidia nForce3 250Gb)
whenever I try to capture with my new computer using an All-in-Wonder 9800 Pro

ati and nvidia drivers could be conflicting.

is onboard video disabled? is there bios update?

another wondering if your agp in bios is set correctly, from 2x, 4x, 6x, 8x agp slot speeds.

try safe mode and device manager make sure you have no duplicates of video / sound / firewire / usb drivers if do, remove all and reinstall after a reboot to normal mode.

make sure any pci, either video, sound or capature card is pluged into pci slot 1, ((normal slot closes to agp slot))

using amd cpu, guessing a via chipset for the mother board, make sure you have www.vaitech.com all in one or what ever the name is now, drivers. and then uninstall / reinstall video, sound, capture drivers.

last but least try lower seting of catpure instead of 640,480 try lowest seting then move up checking for audio sync.

[offline]

IMHO: Uncompressed is not best. All else being equal you want the codec that gives the best compression. That makes Huffyuv best because, being lossless, its output is equal in quality to an uncompressed AVI, but only takes up between a half or third of the space. The reduced bandwidth requirement also means fewer dropped frames etc.

But the higher DATA bandwith requirement can
cause more dropped frames. Just FYI

@ Lordsmurf: Huffy at default is lossless. MJPEG
even at highest quality "20" is lossy.

[racerxnet]

Looks like you are running XP with virtual IRQ's. The issue as stated is not with the onboard sound or Audigy. You should be able to force the devices to other IRQ's in the MB bios. I have forced devices to other IRQ's because of sharing between the RT board and the audio on the same channel.

What is the setting under device - computer - ACPI?? This is a known issue with the Audigy cards. Disable the com ports if you are not using them, you now released 2 IRQ's. Quit using virtual IRQ's in XP. Use a USB mouse and IRQ 12 is now free. Here is a link on the PCI latency issues with Audigy cards. http://www.elderscrolls.com/forums/index.php?showtopic=31185&st=0
http://www.elderscrolls.com/forums/index.php?showtopic=31182

"UPDATE:
OK, the latency for the AGP bus for ATI cards is indeed 255! even when you select 32 in your BIOS.

What the author or the article below claims is that this fixes some stuttering in games but moreover get rids of audio popping and cracking issues, due to some devices taking up to much CPU time (high latency).
with the program you can also change the latency from 32 to another you desire (remember it has to something which can be divided by 8)."

Good link on sound cards: http://www.3dss-forums.com/cgi-bin/wwwthreads/wwwthreads.pl?Cat=


MAK

[mpack]

But the higher DATA bandwith requirement can
cause more dropped frames. Just FYI

I don't understand that comment. The comparison was Huffyuv vs Uncompressed. Huffyuv reduces the data bandwidth requirement in every sense that I'm aware of, relative to capturing uncompressed. Huffyuv may require more CPU, which could cause dropped frames - but I'm pretty sure that is not the issue on most modern PCs... the bottleneck these days (for this application) is the system bus, coupled with the speed of the hard disk.

On Huffyuv: technically, Huffyuv is not completely lossless in all circumstances. If you enable the "Convert to YUY2" option and the source is not YUY2 then it involves a color transform which might involve a small loss. In all practical respects however, it is lossless. If the YUY2 mode is enabled and the source is YUY2 then it is literally lossless - the decoded YUY2 output is identical to the YUY2 input.

MJPEG is lossy, period. There is no other way it can get the required compression ratio. There is a lossless mode in the full JPEG standard, but not in baseline JPEG (which uses the 8bit DCT+Huffman method exclusively), and MJPEG is baseline JPEG. I should perhaps mention that I very recently implemented both sides of an MJPEG codec on a Blackfin DSP, and I've been working with JPEG codecs for... more than a decade anyway... so I know whereof I speak. Quite a trick getting a Blackfin to do JPEG encode full size PAL frame at the PAL frame rate!

[offline]

You stated:

mpack: The reduced bandwidth requirement also means fewer dropped frames etc.

I then stated:

offline: But the higher DATA bandwith requirement can
cause more dropped frames. Just FYI

As compression is reduced, net data
transfer is increased, which also can lead to
frame loss. This effects the very bottleneck
you refer to in your second post - that of

"the system bus, coupled with the speed of the hard disk." (mpack)"

The rest of your second post I have no problem with,
however I'd like to point out:

a) I never said huffy was lossless in all cirumstances

b) I never said MJPEG was not lossless

c) I never talked about JPEG

d) I really don't care if you have had 10 years experience. You talked about having less frame
loss via huffy due to decreased bandwidth. I
merely provided the necessary counter point.

[Ron B]

Hello again-I hope vaporeon800 is working his problems out. I'm just saying, and I may be wrong, but my philosophy is that you have to get your hardware problems straightened out before you start in on the software.

[mpack]

a) I never said huffy was lossless in all cirumstances

You misunderstand - while I included a quote of yours, I was responding to points raised generally in the thread, not necessarily to points raised specifically by you. I'm sorry if this was not clear.

I'm still not sure what you are saying about data bandwidth: "as compression is reduced the data bandwidth increases" - that is what the word "compression" means isn't it? And it also just repeating what I said to begin with (although what I actually said was that, as compression is applied the bandwidth required is less, which is just describing the other side of the same coin...), so I'm still not at all sure what point you were making...

If you meant to say that as compression is increased the data bandwidth also increases then that would be the opposite of what I was saying, and I'd be very interested in hearing the explanation of such a surprising claim...

[offline]

Your point: Huffy can reduce frameloss via reduced cpu use
My point: Huffy can also increase frameloss via increased data load to the HDD.

simple

[mpack]

Your point: Huffy can reduce frameloss via reduced cpu use

No, that wasn't my point. On the contrary, I said that Huffy increases CPU use - but on modern PCs I don't think that is a problem.

My point was that Huffy reduces the data size, which means that less data needs to cross the PCI bus on the way to the hard disk, and less data needs to be written by the hard disk itself, both of which mean that you can get away with a slower bus or hard disk - or equivalently - that you will get fewer dropped frames for a given bus speed / hard disk speed.

[mpack]

My point: Huffy can also increase frameloss via increased data load to the HDD.

How exactly does Huffyuv increase the data load? There is less data with Huffyuv, not more, so how can less data cause an increase in the data load?

[Soopafresh]

My Spirit Guide says the power supply to the PC is bad. Power, heat, or RAM.

Chief Tecumsa has spoken....

[Brad]

Okay long story short, I now have both a Sound Blaster Live! 24-bit and a different Sound Blaster Audigy 2 ZS (so I'm thinking we can rule out the card being defective).

The Live! 24-bit works fine in AVI_IO with no frame drops and perfect synch as far as I can see, though oddly it performs about the same as the Audigy 2 ZS in VVCR and VDub. HOWEVER, the line-in level is very low even with Master, Line-In playback, and Line-In recording at maximum. I can fix this after capturing by amplifying it in software I guess, but I'd prefer not to have to add another step to encoding.. plus I find that the sound quality of the Live! is lower than that of the Audigy (not surprising of course, except the fact that I can tell the difference even on my crappy speakers). So I'd rather get the Audigy 2 ZS working properly than use this card.

Putting the Audigy 2 ZS in each PCI slot (with no other PCI devices in - I took out the ATA controller card to test) resulted in no difference to capturing. I did find that it was assigned different IRQs depending on where I put it, and in slot 1, it shared "PCI 16" with the video card.

Currently I have it in slot 3, with the ATA controller card in slot 4, just because that placement is the most convenient at the moment.

I also tried the "PAX" drivers from http://www.driverheaven.net/showthread.php?t=63660 with no difference.

with your statment of you get lost in both onboard sound and with the add in sound card, the problem is not with either, but system settings and drivers.

with statment of having a nvidia built on video card on the motherboard and adding a all and wonder to the system if ya not having conflicts there.

perhaps reading it wrong
Motherboard: MSI K8N Neo Platinum (nVidia nForce3 250Gb)
whenever I try to capture with my new computer using an All-in-Wonder 9800 Pro

ati and nvidia drivers could be conflicting.

is onboard video disabled? is there bios update?

No no no, nVidia nForce3 250Gb is the name of the chipset. There is no onboard video.

Looks like you are running XP with virtual IRQ's. The issue as stated is not with the onboard sound or Audigy. You should be able to force the devices to other IRQ's in the MB bios. I have forced devices to other IRQ's because of sharing between the RT board and the audio on the same channel.

Running XP, yes. I suppose it's using virtual IRQs based on what I've read. I'm using version 1.4 of the Award BIOS for my board, and the only options I see for the IRQs (3-5, 7, 9, 10-15 are the only ones listed) are "PCI Device" and "Reserved".

What is the setting under device - computer - ACPI?? This is a known issue with the Audigy cards. Disable the com ports if you are not using them, you now released 2 IRQ's.

It's listed as "ACPI Uniprocessor PC". There's only one COM port, and I'm not using it, but it seems I have a bunch of free IRQs from 1-15 anyway: http://img85.exs.cx/img85/7917/devicemanager5fg.png

Will disabling the COM1 port really help?

Quit using virtual IRQ's in XP.

How might I do that?

Use a USB mouse and IRQ 12 is now free.

No problem there, already using a USB mouse and keyboard.

Here is a link on the PCI latency issues with Audigy cards. http://www.elderscrolls.com/forums/index.php?showtopic=31185&st=0
http://www.elderscrolls.com/forums/index.php?showtopic=31182

"UPDATE:
OK, the latency for the AGP bus for ATI cards is indeed 255! even when you select 32 in your BIOS.

What the author or the article below claims is that this fixes some stuttering in games but moreover get rids of audio popping and cracking issues, due to some devices taking up to much CPU time (high latency).
with the program you can also change the latency from 32 to another you desire (remember it has to something which can be divided by 8 )."

Erm, the program mentioned there shows that my graphics card is already using only 32 (64 in total I guess, if you add the 32 for the "secondary"): http://img80.exs.cx/img80/9899/pcilatency0tj.png

At any rate, changing the Audigy 2 ZS's latency to 64 and then 128 didn't make any difference.

Interestingly, Windows installed the driver for the Creative Game Port even though I don't even have the darned thing plugged in (or even taken out of the box :P).

[lordsmurf]

ATI AIW cards were designed for ATI MMC. If you insist on other software, buy a different video card. That's likely part of the problem.

Be sure the audio settings in windows, the RECORDING settings, are at good levels.

To say that you can hear the difference between those two cards on cheap speakers is probably more psychological than factual. It sounds better because you think it sounds better. People hate to hear this and love to argue it, but it's usually the truth. Same can be said about many things.

It may be something else, and you may run around in circles trying to find it, but these are my first suggestions, and they're usually the correct solutions.

[Brad]

ATI AIW cards were designed for ATI MMC. If you insist on other software, buy a different video card. That's likely part of the problem.

Like I said, MMC was no better for synch. I'll check later if it's any better for sound levels on the Live! card but I doubt it.

Be sure the audio settings in windows, the RECORDING settings, are at good levels.

Line-In recording level at max and the captured level is still way too low. At around 80% it's good on the Audigy 2 ZS.

To say that you can hear the difference between those two cards on cheap speakers is probably more psychological than factual. It sounds better because you think it sounds better. People hate to hear this and love to argue it, but it's usually the truth. Same can be said about many things.

Yeah, I was gonna say that actually.

[Brad]

Yep, no difference in volume capping in MMC as compared to AVI_IO.

[lordsmurf]

Hmmmmm.... the hunt is on... good luck. If I think of anything else, I'll post back.