If you have a firewire port on your laptop, same as a USB 2.0, how does the Firewire signal NOT have to overcome the same path on its way throughout your computer?
Don't both signals end up travelling the motherboard and have the same obstacles?
Yes and no. If your drivers are written properly to use DCL programs, FireWire puts most of the data path logic out on the controller chip itself. That means that the FireWire controller can basically support your audio card even if the CPU is busy doing other things. The device sends a message that says, "I have a frame of audio," where the size of the frame is dependent on the hardware, driver, buffer size, etc., but IIRC is typically maybe a couple hundred samples or so. The FireWire controller receives that message, copies the audio from the device into RAM itself, then sends an interrupt to your computer that says, "Something is ready for you to do." The computer says "Oh crap, did that come from FireWire or some other device," then decides that it came from FireWire, reads the DCL status, sees that a chunk of audio is ready and waiting in RAM, and tells the audio app that the data is ready to be read from the driver's ring buffer or copies it from the driver's ring buffer into the application's ring buffer, depending on the OS. Oh, and the controller has already determined when the signal from the device occurred, so there's a time stamp on that buffer for your convenience.
With USB, the device sends an interrupt and says "I have a frame of audio ready for you." The CPU says "Oh crap, did that come from USB or some other device," decides that it came from USB, then sends a message to read a chunk of data. During this delay, if it is long enough, the audio device may have already overwritten the start of that chunk of audio with new data. Even if it hasn't, though, the CPU then goes back to whatever it was working on. The USB controller then wakes it up a little later and says "I have a packet of raw data from a USB device. Insert the usual decision about which device the interrupt came from again. The CPU reads the packet from the USB controller's data buffer and copies it into the final location. It then repeats this process for the next packet. It may take several packets to read a single chunk of the audio, during which time it has had many opportunities for the audio device to have caught up and overwritten data before it gets read. Somewhere in this process, the software approximates when the packet of data occurred.
Now on top of all these problems, the timing of when the packet occurred is critical. Why? Because the USB 1.1 audio spec (and many USB 2.0 audio devices unfortunately still use the broken 1.1 spec at 2.0 speeds) is fundamentally broken and doesn't indicate whether the device has one clock or two. That means that when you set the input rate and output rate to different values, it may or may not work. IIRC, it also has no way for the device to tell the computer about a sample rate change except to tell the computer it only supports a single sample rate and then disappear and reappear showing a new set of supported sample rates containing only the new sample rate if you switch rates on the device. So now you have to guess whether your sample rate is correct or not based on whether the audio chunk has the expected number of samples between the last two time stamps. If the time stamps aren't precise enough (and this is really hard to get right if the hardware doesn't do it for you), wham, you've just changed sample rates and the USB audio driver can get very, very confused.
Worse, as a result of the need to do this guessing in those extreme cases, the specification has strict limits on the amount of variation in the sample count from one audio packet to the next. Unfortunately, many audio interfaces flagrantly ignore that part of the spec, resulting in all sorts of confusion about what sample rate is actually being used by the device. This is when you end up in crackle hell.
If you understood all or even most of what I just said, you should be just about on the floor laughing or crying right now (or laughing so hard that you cry).
And then, there are all the places in the USB audio spec where you can lose isochronous reservations and suddenly no longer have enough bandwidth to guarantee that you can shove your data across the wire. With FireWire, the only way you can lose your isoch reservation is if you have two computers both with over 200 Mbps reserved and you plug a FireWire cable between them and join the networks....
