Hulttio said:
Paul said:
I have an A7V880, Crucial RAM, Matrox G550 AGP video card, an Audigy
Sound Card (with firewire port onboard), and a Athlon 2800+ CPU. I
have tried both XP, XPSP1 and XPSP2.
My problem is this. With the sound card in any PCI slot I cannot get
Adobe Premiere (v6.0, 6.5 or Elements) to capture video correctly. The
video drops frames at a near 50% rate. The other thing is that if the
sound card is in one PCI slot it will NOT even detect the Sony
DCR-TRV460 as a FW device, but in other slots it detects it, but the
dropped frame rate is phenomenally bad (nearly 50%). I have
successfully done this process in an A7V600 with all the same hardware
(and more) and never saw a problem enumerating the camera OR capturing
video. I have contacted the following tech support departments to no
avail so far: ASUS, Creative Labs, Microsoft and Sony. ASUS has been
the most helpful but needs information from Creative Labs to continue.
Anyone got any ideas??
Thanks in advance!!
dbmdude
PS I have looked into the hotfixes by Microsoft and none fixed the
problem.
Try the following:
1) BIOS - PCI Delayed Transaction [Enabled]
This is a PCI bus optimization, where a slow PCI device is "polled"
until its response is ready. Faster PCI device operations
can occur while waiting for the slow device to respond with
its data. This improves overall PCI bus bandwidth available to
the user.
2) BIOS - PCI Latency Timer [32]
This timer, AFAIK, defines the maximum time that a bus master
may sit on the bus. Lower values mean that multiple PCI devices
will share the bus more fairly. A lower value means a low bandwidth
PCI devices can do the cycles it needs, in the presence of a
high bandwidth PCI device.
3) PCI slots. The IRQ table in the manual says PCI slot 1 (nearest
the processor) and PCI slot 3, don't share an interrupt signal
with any other devices. Placing your sound card in one of those
two slots, should allow the lowest interrupt service latency.
I would use slot 1, as at least no other card in a PCI slot
can preempt a card in slot 1.
In cases in the past, there have be interactions between Firewire
chips and certain disk controllers. It seems some RAID controllers
that sit on the PCI bus, will cause dropped frames, and it might
even be caused by a poorly written driver, as much as the hardware
itself. You may have to experiment with how your disk drive is
connected to the computer, to get a configuration that doesn't
drop frames. For example, you might even find a USB2 connected
disk works better than what you are doing now.
You might want to install the latest Via 4-in-1 hyperion driver,
to take advantage of any chipset patches issued by Via for their
chipsets.
http://www.viaarena.com/default.aspx?PageID=2
Look for a "chipset" driver.
As far as I can see in Google, the firewire port on the Audigy
seems to work for people, so I don't necessarily see the need
to purchase yet another separate Firewire controller card, to
fix this problem.
Please post back if any of the above helps, as others can benefit
from your experiences.
HTH,
Paul
dbmdude,
paul gave good information, however i think that the bios needs to
upgrade first to latest to get best starting point. audigy is a little
problematic because it sucks 2 irq, one for audio and second to firewire
this might sometimes cause broblems because eg a7v880 have 2 free pci
slots like paul wrote but those are 1 and 3. I mean that when you
connect your audigy to pci slot 1 then firewire takes next irq and then
it shares with agp and pci slots 2 and 5 and if you put audigy to pci
slot 3 then firewire shares with onboard gigabit lan.
however early bioses contains bug with pci audio card so update bios to
latest (1008) and test pci slot 3, one thing if you don't need onboard
lan then disable it but i think that you need that so update it's driver
from
http://www.marvell.com/drivers/search.do
i think that you get your rig to work since a7v600 worked fine as you
said. sorry my little bad english.
Maybe I should revise my slot recommendation
First, a little background (I hope this doesn't bore anyone).
A PCI card has four interrupt signals. They are INTA, INTB, INTC, INTD.
Most PCI cards are single function, and they will assert the INTA
signal only. The other pins would be unused. A dual function card
would use INTA for one device and INTB for a second device, assuming
the PCI card designer felt that the service latency made it necessary
to use two separate wires. You could make a dual function card,
and join two functions to the INTA pin if you wanted. Thus, when
we are told the Audigy is a dual function card, we don't know a priori,
whether sound and firewire both use INTA, or one uses INTA and the
other uses INTB.
The PCI spec states:
"All PCI device drivers must be able to share an interrupt
(chaining) with any other logical device including devices
in the same multi-function package."
The chipset on the motherboard has a limited number of interrupt
signals. On some chipsets, there are only four signals dedicated
for PCI devices (PIRQA .. PIRQD). On other chipsets, there are
eight signals (P_INTA .. P_INTH). Server chipsets sometimes have
tons of signals, enough for _every_ interrupt signal on the
motherboard to be private.
The four interrupt pins on each PCI slot have to be wired to something.
There is a default wiring pattern, called the "PCI swizzle", where a
copper wire is wired to INTA on the first slot, then INTB on the
second slot, INTC on the third slot and so on, and then the pattern
repeats. A second copper wire goes to INTB on the first slot, INTC
on the second slot, INTD on the third slot, and INTA on the fourth
slot. This rotating diagonal wiring pattern is termed the "swizzle".
Onboard PCI devices on the motherboard are also wired into the
swizzle, but as the onboard PCI devices are single function
devices, it is arbitrary as to where they get wired.
The AGP slot has two interrupt signals. They are INTA and INTB.
This allows an AGP card to be a dual function device, and have
two interrupt signals if it wants. The AGP is also wired into
the swizzle pattern.
The Asus IRQ table for a desktop board, only seems to provide details
for how INTA on each slot is wired (i.e. the primary interrupt wire
is documented, but not how multifunction cards would be wired).
The Asus table contains one quarter of the actual wiring pattern,
and as well, the table is frequently rife with errors. This means
when a dual function card like an Audigy with 1394 is present, we
can guess that the INTB signals on each slot, follow the regular
pattern, but can never really be sure. (Some Asus server
manuals actually contain the full wiring pattern, and apparently
the tech writers feel that server owners can handle this
information.)
If the Audigy is actually using two or more of its INTx pins, it
will be pretty hard to predict what sharing will occur. You would
almost need to move the card from slot to slot, and use Sandra to
examine the IRQ number assignments, to see a pattern emerging.
If the Audigy was my card, I would want to ensure the interrupt
signal for the sound subsystem, received a private copper wire.
Thus, if the Audigy had its sound interrupt on pin INTA, we
could look in the Asus table, and assume slot 1 or slot 3 would
give INTA a unique interrupt copper wire.
But, we are unlikely to be able to give a secondary function on
such a card, its own private copper wire, at the same time.
Sound is notorious for being intolerant of interrupt latency,
while other functions like AGP, ethernet, USB, and the like,
can tolerate latency and can share with other devices. As a
result, comparing the requirements of the sound portion of
the Audigy to the 1394 portion, I would give more careful
treatment to the sound portion.
Now, back to the dropped frames. The frame droppage is going to
be due more to interference from some other device, like even
some device inside the chipset itself, than maybe an interrupt line
issue. If you are dropping 50% of the frames, then some
software interference has to be involved, as modern chipsets
simply aren't decrepid enough to be that bad. In past examples,
the interfering device was the disk drive that the 1394 data
was being captured to. Changing the port used for the disk,
i.e. move from RAID chip to IDE, or use a SATA, or use a
Firewire disk, or use a USB disk...
So, I guess my original answer was "off in the weeds" in
terms of the slot recommendation. My slot recommendation was
made to make sure the sound on the Audigy would work. My slot
recommendation will do nothing to fix the 1394/Firewire problem
(simply because the Asus manual only documents 25% of the slot
wiring for interrupts, so the other 75% of the wiring can
only be determined by using Sandra, and repeatedly moving
the card from slot to slot).
AFAIK, the swizzle wiring pattern mentioned above, is purely for
providing a rough load balance on the wires, and was never intended
to provide "private" interrupt lines. The fact that certain
companies can get away with making PCI cards that don't function
properly in this environment, is a testiment to customer tolerance
of the problem.
One funny thing about this question, is when I searched Google
to answer this question originally, the Audigy actually has a good
reputation concerning frame loss while doing DV capture to the
1394 port. Since that is the case, that people are able to use
their Audigy for DV capture, this means that purchasing a
separate Firewire card is unlikely to make a difference. It
is something about the motherboard (driver for disk or a
Via chipset problem) that is likely to be at the root of the
problem.
Paul
