Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Thu, 2008-04-17 at 22:56 -0400, Mark J. Dulcey wrote: > The raw data rate of DV video isn't actually all that high; only about > 30Mbps. Most video cameras actually only implement the 100Mbps data rate > over FireWire (FireWire 400 can run at 100, 200, or 400Mbps, the actual > speed is negotiated by the devices) which is more than fast enough; > 400Mbps is overkill. True. > One advantage of FireWire over USB is that the protocol provides for > bandwidth-sensitive devices. A FireWire device can reserve a portion of > the bus and is then guaranteed to get what it asks for, so you can put > other devices on a FireWire bus at the same time as a video camera and > still be assured that the video transfer will succeed in real time. USB > has no such provision. But most computers these days have multiple USB > ports, so an easy solution is to give the high-speed device a port all > to itself. But wait, there's more. In addition to other devices on the bus causing issues, USB is entirely dependent on the host cpu to handle bus arbitration, so any significant load on your cpu tank USB throughput in a hurry. FireWire has very low cpu overhead, as FireWire controllers are WAY more intelligent. Basically, the host cpu has nothing more to do that queue up a series of DMA descriptors, and the FireWire controller will fetch them from the device and put them straight into host memory. Nb: I've spent the last ~5 months working heavily on the new "juju" Linux kernel firewire driver stack (*almost* everything Just Works now...). This is only the tip of the iceberg, I can tell ya a whole lot more about how the data gets from the camera to disk, right down to the contents of the isochronous receive context control register level... :) -- Jarod Wilson [hidden email] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Discuss mailing list [hidden email] http://lists.blu.org/mailman/listinfo/discuss
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |