I hope someone can help me out.  I've been running SONAR with a single FirePod on Windows 7 64-bit without any issues.  Recently, I decided to purchase a second FirePod and daisy chain them through FireWire.  This is where all my troubles started. 
 
Although the two units sync and "talk" to each other, I noticed that in the Device Manager one unit is listed as as "FirePod" and the other as a "FP 10".  Therefore, the firmware must be different on one, but they still communicate ok.
 
First problem was that upon trying to use SONAR I would get "The audio engine has stopped" messages even when SONAR was idle and nothing was using the CPU.  After research, I was told to switch to the "legacy" OHCI driver.  I do have a Texas Instruments chipset.  Once I did that I thought all my troubles were over.  SONAR seemed to be happy, but now I'll get unexpected BSODs.  Sometimes the system will run for a few hours before this happens but eventually it will happen.  I analyzed the dump file withe a tool and the following information was returned:
 
crash dump file: C:\Windows\Minidump\082613-60528-01.dmp
This was probably caused by the following module: ohci1394.sys (0xFFFFF88003F15988)
Bugcheck code: 0xD1 (0x0, 0x2, 0x0, 0xFFFFF88003F15988)
Error: DRIVER_IRQL_NOT_LESS_OR_EQUAL
file path: C:\Windows\system32\drivers\ohci1394.sys
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: 1394 OpenHCI Port Driver
Bug check description: This indicates that a kernel-mode driver attempted to access pageable memory at a process IRQL that was too high.
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem.
 
At this point I'm stuck and don't know what to do.  Give up on using two FirePods?  Give up on FireWire and try USB?  Hope someone has a solution for this.  Thanks...
 
Dave White

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.

Good advice to make sure each unit is working fine (when run individually)... and to make sure both units have the latest firmware.
 
Once you've done that, I'd try a couple of things:

• Connect each FirePod to its own Firewire port (not daisy-chained)
• Try a different TI chipset Firewire controller.

Some audio interfaces (Mackie and Tascam come to mind) are very particular about the Firewire controller... even if you're running a TI chipset unit.

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've been advised not to daisychain identical FW interfaces. And you probably already know ASIO mode doesn't like multiple devices. I looked at your crash dump and a couple things stand out. Different device names, equal or not less IRQ, and page fault.
 
Looks like your machine is trying to make the second device different from the first, and not different, at the same time. Not hard to see how the table of contents of the pageswap files are getting confused, a pretty standard source of bluescreens. (loose terminology here for simplicity's sake)
 
My general impression is that dual interfaces that play well together are the exception, not the rule. You can keep tweaking it, hoping for the best, or hang the second interface from another PC and connect them only on the audio side, or look at some kind of ADAT type solution to expand your I/O options. Option A costs nothing but time, so you can try that while pursuing B or C.
 
I've always been inclined, in the back of my mind, to see what happens with two FW interfaces, on two different machines, both running DAWs, connected by ADAT both ways, possibly twice. Sort of the digital extension of matched 24 track analog tape machines, synced, and multiplexed, with the benefits of very low generational losses. Haven't tried it yet because one PC/interface, w 2 Behr ADA8000's is doing all I need it to do so far. Be interested in hearing results if you go this route.
 
Good luck!

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)?

My motherboard has an internal Intel graphics chipset/driver and therefore I was able to remove the NVIDIA card.  Now, only the USB controller shares IRQ 16 with the FireWire card.

In spite of removing the sharing with the video card, I still got audio dropouts, but one FirePod by itself works perfectly.

However, I think I know what the problem is.  I currently have two FirePods hooked up along with a dedicated hard drive to a PCI FireWire 400 card.  My motherboard has open PCI-express slots which offer greater speed, do not share a bus with other devices since they have dedicated "lanes", and they support bi-directional communication far better than the older PCI technology.

My current theory is that I don't really have any conflicts or problems in my Windows setup - just that I'm trying to send and receive too much bandwidth through an older PCI card.

Therefore, I'm going to try upgrading to a PCIe (express) x1 card with a Texas Instruments chipset and see if that fixes my audio dropout problem.

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

Hello... before you start to throw Money at a problem, I would suggest a couple tests, using just the FP units, Sonar, existing FW card, and your PC...
1) Go in to your BIO's and go to PnP PCI configuation... type in/force a new interrupt number for your PCI slot, save settings, Reboot.
2) Remove your exterior hardrive from your Firewire card.
3) Try using higher Latency settings, when both units are Linked together... using Sonar or/and Presonus UC software.
4) Adjust Master/Slave configuations... using Presonus UC software.
5) Use the Presonus UC software to enable/disable I/O's and latency settings ONLY, ONE TIME configuation setup, DO not have it running in the background when doing any AUDIO WORK in SONAR... That program running with SONAR, will use up CPU and Program resources... I never ever run the program unless I need a I/O or latency setting change to my Units, Then I close it before starting SONAR, basically I use it to configure the Driver and what is seen by SONAR, But I do not use it for any realtime Audio, mixing, or monitoring, as a increase of DROPOUTs will Occur.
 

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.