BSOD Crashes With Windows 7-64bit Firewire and Daisy-Chained FirePods

Hello... i'm using the WIN7 64 6.1.76000.16385 Texas intruments 1394 OHCI driver... with two Presonus Projects.
 
1) I would get both units with the same Firmware driver... you need the latest Download of their Presonus User Control program.
2)Firewire out card to input 1 FP1, input 2 FP1 to input 1 FP2.
3)I would verify that your USED/new unit works flawlessly by it's self... for a long period of time... could have hidden problem?
4)search the WEB for further information on the FP link topics... I thought I read a reliability problems with doing that... and the PROJECT versions came out, having no problem with linking 3 units.

Each unit works fine in isolation.  I tried connecting the second FirePod to another FireWire port instead of daisy chaining it and that made no difference.  PreSonus tech support tells me that the firmware difference should not matter.  They lean now toward a Windows ACPI interrupt sharing problem: the 1394 FireWire card, NVIDIA GeForce 8400 GS card and USB host controller - 3A37 as well as a PCI express root port.  They are all sharing IRQ 16.
 
I tried switching back to the legacy OHCI driver tonight and got the BSOD running SONAR after about 10 minutes.  With the newer OHCI driver I don't get BSODs, just "The audio engine has unexpectedly stopped" messages.  Interestingly, SONAR always reports that the new used "FP 10" unit is the one with trouble, but this unit seemed to run fine in isolation.
 
PreSonus recommends moving the 1394 card to another slot in order to try and force Windows to re-assign the interrupt.  To update the firmware of my first FirePod I unfortunately need to find a Windows XP machine since the updater will corrupt the unit if run on Windows 7, 64-bit.
 
I've done a bunch of audio optimizations to Windows and none have resolved the issue.  SONAR can be sitting idle doing nothing and eventually the error message will pop up.

I was successfully able to upgrade the firmware of my FirePod to an FP-10. This did not help to resolve "The audio engine has stopped unexpectedly" problem. I've just about exhausted all ideas. The only thing left is the ACPI interrupt sharing. Unfortunately, my motherboard has a single PCI slot so I can't move the 1394 FireWire card to another slot.

Sharing IRQ 16:
Intel(R) 4 Series Chipset PCI Express Root Port - 2E21
Intel(R) ICH10 Family USB Universal Host Controller - 3A37
Texas Instruments 1394 OHCI Compliant Host Controller
NVIDIA GeForce 8400 GS

Windows seems to have a bunch of higher level interrupts but I don't think you can force Windows to assign a device to a particular interrupt with ACPI. Perhaps there is a way I can test in Windows "safe mode" and see what triggers the audio dropouts.

What I don't understand is that if the interrupt is truly the issue, then why does each FirePod unit work standalone with SONAR? If this were an interrupt issue wouldn't a single FirePod also have problems?
 
I did not know ASIO does not like multiple devices.  At this point I'm looking at new hardware.  I need more than 8 channels of input and originally I thought daisy chaining two FirePods would be the way to go.  This is not working.  Should I purchase an audio interface with an ADAT input/output and daisy-chain that way to gain 16 or more input channels (e.g. Mackie Onyx Blackbird)?

FWIW, The PCI bus has more bandwidth than Firewire (by far)... so I seriously doubt that is the problem.

The PCIe card is my last desperate attempt to resolve the issue.  The "audio engine has stopped unexpectedly" occurs even when SONAR is sitting doing nothing. 
 
There is an FP-10 control panel which I exited and the problem persists.  I also tried setting the latency to an "insane" level of 40ms - the maximum allowed - and the dropout still occurs.  Again, that dropout occurs when I have SONAR sitting idle.  All the channels are armed for record but that is it. 
 
Today I stopped all services accept those needed to run SONAR and again this did not help.  I also tried increasing the buffer sizes and the DropoutMSec parameters in SONAR.
 
The one interesting thing I noted is the following discrepancy.  The utility DPC Latency Checker *never* shows there is a problem; the current latency is always in the "green" even when a dropout occurs.  However, the utility LatencyMon indicates there is a problem when measuring "Interrupt to user process latency".  When I use that tool to measure "Kernel time latency" instead of "Interrupt to user process latency" LatencyMon says there is not an issue.  Using LatencyMon I've eliminated all the drivers that seemed to be the culprit starting with the NVIDIA video card and the network card.  The remaining contenders are the ACPI driver and the USBPORT driver.  The PCI card is sharing IRQ16 with the USB controller.
 
Perhaps there is a compatibility issue with my motherboard and/or the dual CPU?
 
Pentium(R) Dual-Core CPU E5700 @ 3.00GHZ
Family 6, Ext. Family 6, Model 7,  Ext Model 17, Stepping A, Revision R0
Motherboard: Dell 018D1Y A00, Chipset Intel G45/G43 Rev A3, Southbridge Intel 82801JR (ICH10R) Rev 00, LPCIO ITE IT8720
BIOS Dell Inc. A06 12/01/2010
4 gig DDR3 memory
 
So I'm left with the problem where no dropouts occur with a single FirePod and they always occur with daisy-chained FirePods.  The dropouts occur when SONAR is idle.  The dropouts occur when just running media player and using the daisy-chained FirePod as the default playback device.  I've eliminated everything I can think of and the only thing left is the interrupt sharing with the PCI card and perhaps a CPU compatability issue.

Even though I have the PCIe card on order, I may have found the issue.  I will have to continue testing for next couple of days.

First, the 1394 OHCI Legacy driver must be used, not the latest Microsoft driver or the Texas Instruments Compliant driver.  The latest driver will not cause a BSOD, but it is unusable - audio dropouts.  Same with the TI Compliant driver.

Second, when I used the Legacy driver before I got BSODs.  However, examination of the dump files revealed two drivers: the legacy 1394 OHCI driver, and, mozy.sys. I use Mozy as a backup service and I thought I had shutdown the Mozy service for my testing.  However, mozy.sys is still used by a process called mozystat.exe which still runs in the background even if the service is shutdown.

When I killed that process, SONAR has been running fine.  I was able to replicate a BSOD by having SONAR and mozystat.exe running at the same time. Case opened with Mozy but I don't expect a miracle - solution may be to ensure Mozy (and any of its hidden processes) is not running when SONAR is.  If the latest Microsoft driver is used, there is no BSOD caused by Mozy but it is unusable with SONAR and the FirePods due to the audio dropouts.