Golden
New member
are these the same? sorry dudes, I'm new to this tech shit. I just got a lacie 400 PCI card, noticed it says 1394a on the package.
SouthSIDE Glen
independentrecording.net
Yeah, they're the same thing. Here's how I understand the breakdown: 1394a - sometimes now called Firewire400 - referrs to the original Firewire spec, originally called just 1394.Golden said:
The "a" designation is to differentiate it from the newer Firewire800 spec - a.k.a. 1394b, which is a double-speed implementation of the original Firewire, designed to compete against USB 2.0.
G.
D
dementedchord
Psychotic State alumni ch
cant swear to it but i thought the "a" was when they added bus power to the original spec...
dgatwood
is out. Leave a message.
dementedchord said:
No. 1394a and 1394 are both FireWire 400. IIRC, the "a" was added when they tightened up a few of the specs to include certain fixes that were already included in the beta (FireWire 800) spec.
The big difference I'm aware of is that 1394a specifies limitations on inrush current. A few 1394 devices don't comply with the maximum inrush current specs specified in 1394a, and thus will cause a fully conformant 1394a interface to shut off power to the device instantly when you plug it in.
For example, unless they fixed it recently, the Presonus FireBox is not compatible with modern Macintosh computers because it is not 1394a-compliant. You have to use it with an external power supply when you power it up initially. You can then yank the external supply after you plug the device into the computer.
SouthSIDE Glen
independentrecording.net
Is this an issue in both directions? For example, what if one has an older 1394 i/f on the computer side and a newer 1394a external device?dgatwood said:
G.
dgatwood
is out. Leave a message.
SouthSIDE Glen said:
Yes, with an older 1394 card and a 1394a device, the device will work just fine, with the caveat that because the older 1394 card doesn't provide inrush protection, if you plug the connector in at an angle and short a couple of pins, you can blow out the PHY on the card or the device. That's what the 1394a/b inrush protection limits were designed to protect against.
Power-providing 1394a gear typically uses a self-resetting fuse to ensure that if shit happens, you don't start torching silicon or blowing any real fuses.
Golden
New member
dgatwood, I love your avatar! 
F
fishkarma
New member
SouthSIDE Glen said:
They didn't really need to compete with USB 2.0 from Firewire 400
Firewire 400 was 400 megabits/s continuous
USB 2.0 is 480 burst
Meaning that USB 2.0 is faster for short times but over the long haul 400 is more constant.
Fw800 is just overkill against USB 2.0 and blows it out of the water! not complaining though Fw800 rocks!
D
dementedchord
Psychotic State alumni ch
dgatwood said:
good info.. appreciate ya brother...
dgatwood
is out. Leave a message.
fishkarma said:
With an infinitely fast CPU, USB could probably sustain pretty close to 480 Mbps. The problem is how much CPU it currently eats while doing so: nearly all of it.
The device has to be serviced very frequently to sustain those rates because the controller can't do anything without CPU intervention. As a result, the practical throughput is typically bounded at more like 360 Mbps.By uploading FireWire DCL/NuDCL programs to the FireWire controller, you can sustain 400 Mbps with the CPU crashed. It's just a much smarter controller design.
dgatwood
is out. Leave a message.
Golden said:dgatwood, I love your avatar!
Thanks. It's a chunk of a photo I took on the bluffs overlooking the ocean on Highway 1... somewhere south of Monterey, CA.
D
dementedchord
Psychotic State alumni ch
another minor point.... isn't usb a dynamiclly allocated system.... so the total is shared and reserved for other devices on the bus even when they aren't in use????
SouthSIDE Glen
independentrecording.net
Yet they did. There's more to the story than just specs. Apple was losing market share to USB for reasons beyond the techgeek stuff (e.g. the licensing fee, bad marketing tactics, etc.), and had to compete how they could.fishkarma said:
The ironic part is that even Apple has switched from FireWire to USB in one of their own most popular devices. The video iPod now uses USB2 instead of FW.
For most applications concerning the topics on this forum, the theoretical differences between USB and FW, while not entirely irrelevant, tend to be on the academic side. There's more than enough horsepower and bandwidth from the CPU on out to the pipeline with either one to handle the needs of the device using it for all but the most extreme of applications or sloppy of practices.
G.
dgatwood
is out. Leave a message.
SouthSIDE Glen said:
For mass storage, it doesn't make much difference. You'll notice that they aren't streaming 40 channels of audio to the iPod.
SouthSIDE Glen said:
They aren't entirely academic. Using the DCL/NuDCL stuff in FireWire versus CPU-driven USB means that FireWire has a couple of microseconds lower latency than USB. It simply isn't feasible to use as much CPU as would be needed to make USB equal FireWire. You'd never have any spare CPU time for anything else. It could be better than it is, but FireWire will always be capable of lower latency than USB unless someone redesigns USB to be more like FireWire (at a higher cost per port).
That's not the only latency problem, though. Most USB audio silicon also supports a smaller number of chunks per frame than FireWire, resulting in higher latency still (though this is the fault of the interface designers, not of the specification itself).
Also, the USB descriptors for almost all devices that are currently shipping are the 1.0 version, which has some disadvantages in terms of how clock sources are specified, resulting in various overrun/underrun problems that don't occur with FireWire. When most USB devices obey the 2.0 audio class rules, that will get better, but it is likely to take a while. That's one of the reasons that you are much more likely to hear complaints about pops and clicks with USB devices than with FireWire.
Finally, if you routinely max out your CPU with effects, switching from USB to FireWire can easily make that few percent CPU overhead difference that means the difference between glitching and a stable recording/playback experience.
There are very real and noticeable performance advantages to using a smart peer-to-peer bus like FireWire instead of a dumb host-device bus like USB. If everything works for you with USB, great, but that doesn't mean it isn't a really poor technology for audio by comparison.
SouthSIDE Glen
independentrecording.net
All true enough on paper, dgatwood. You know your tech stuff as well as one would expect from someone hailing from Sunnyvale, CAdgatwood said:They aren't entirely academic. Using the DCL/NuDCL stuff in FireWire versus CPU-driven USB means that FireWire has a couple of microseconds lower latency than USB. It simply isn't feasible to use as much CPU as would be needed to make USB equal FireWire. You'd never have any spare CPU time for anything else. It could be better than it is, but FireWire will always be capable of lower latency than USB unless someone redesigns USB to be more like FireWire (at a higher cost per port).
That's not the only latency problem, though. Most USB audio silicon also supports a smaller number of chunks per frame than FireWire, resulting in higher latency still (though this is the fault of the interface designers, not of the specification itself).
Also, the USB descriptors for almost all devices that are currently shipping are the 1.0 version, which has some disadvantages in terms of how clock sources are specified, resulting in various overrun/underrun problems that don't occur with FireWire. When most USB devices obey the 2.0 audio class rules, that will get better, but it is likely to take a while. That's one of the reasons that you are much more likely to hear complaints about pops and clicks with USB devices than with FireWire.
Finally, if you routinely max out your CPU with effects, switching from USB to FireWire can easily make that few percent CPU overhead difference that means the difference between glitching and a stable recording/playback experience.
There are very real and noticeable performance advantages to using a smart peer-to-peer bus like FireWire instead of a dumb host-device bus like USB. If everything works for you with USB, great, but that doesn't mean it isn't a really poor technology for audio by comparison.
. And it's all stuff that needs to be considered by your silicon-wielding compadres designing the devices and software that will use the pipe in question.However I have yet to experience a situation - or even read of a situation on this board in the past two years, or in service in the last thirty - where the choice by a manufacturer to use one pipe or another has negatively affected the performance of the DAW in a way that cost in actual performance or workflow, and that would have been allevaited had they used an alternate pipe.
Latency can be offset in software, if it even crops up as an issue to begin with (I've done all day and all night sessions with USB 1.1 interfaces simultaneously running external drives as well as the audio interface, running into software on stock settings without even having to think about latency once.)
And as far as maxing out a CPU with plugs, if you're in the middle of a mix with more than five or six tracks unlocked/unfrozen at any given time, you're just being sloppy. And (unless you're running Vista on an under-equipped machine, in which case all bets are off anyway
) even your average 3-yr-old home computer can run multiple convolution verbs and mic modelers on that number of tracks without breaking much of a sweat.On the other side of the pipe, it's your fellow design engineers that make sure the right pipe is selected for the device in question so that for those of us on the receiving end, it truely is farily academic. You don't see many, if ANY, manufacturers using USB for more than 8 streams, and even for that few streams, you'll find FW used just as often.
Again I said the differences are not entirely irrelevant. I'm just of the position that when it comes to the question of making a purchasing decision on a piece of hardware, once one accounts for available port usage and future expansion plans, theoretical performance difference issues between the two pipes are a relative non-issue in making the buying decision. Whatever the devices usues will not make or break the performance of the device.
G.
dgatwood
is out. Leave a message.
SouthSIDE Glen said:
That's true for the most part. Latency figures are still important when you're recording or using computers for live sound, though, and particularly when you are recording multiple performers at once. When the signal is coming in from a microphone, nothing you can do in software can speed its way back out of the system through an output.
You can always do zero-latency monitoring (analog pass-thru) if your hardware supports it, of course.
SuperGeek
New member
Fw 800
I like firewire over usb for audio any day
But then my device can use eather FW 400 or FW 800
But getting a new computer and will set up for FW 800
But at the moment i use FW 400 with no bad results.
but in the end its each to there own or if it works for you great
My 2 Watts
I like firewire over usb for audio any day
But then my device can use eather FW 400 or FW 800
But getting a new computer and will set up for FW 800
But at the moment i use FW 400 with no bad results.
but in the end its each to there own or if it works for you great
My 2 Watts
SouthSIDE Glen
independentrecording.net
Again I agree. And again, it's (as I see it, anyway) still rather a moot point there on a practical and macro level for a couple of reasons.dgatwood said:
The first one is related to the reason you mention at the end. If one is live tracking or live mixing a live performance, they will almost certainly be monitoring before the converters, usually from the analog board itself. There's rarely need to monitor post-conversion.
The second one is an even more practical matter; if one is live mixing/live tracking, rare will be the instance where they actually have a real choice between USB and FW; the decision has already been made by the manufacturer. The vast majority (if not all?) of 4- and 8-channel i/fs will be FW only, and anything larger than that will certainly be FW only. With 2-channel i/fs, one is mostly in the realm of USB, with very few, if any actual FW boxes made for that narrow of a data path anyway. Which is fine, because for somthing that small, USB2 is more than robust enough, even with it's technical shortcomings.
Would I design an 8- or 16-channel interface to use USB? Certainly not. FW is the way to go there. But the thing is, everybody knows that and that's the only choice given to the customer anyway. There *is no choice*. And on the bottom end - 2-channel interfaces - there's little to no need to spend the extra for FW because it's just not really necessary. Again, the mfr's know that already as well, which is why the number of 2-channel i/fs that use FW approaces zero. Agian, there is virtually *no choice to be made* by the customer; nor need there be one at that level.
It seems to me that once one pulls away from the tech sheets and schematic diagrams and actually looks at the real products and uses - once one looks at the solutions forest instead of the technical trees - that *for the end user*, it's a pretty academic question.
G.