51–60 of 102 posts
I call this the "invented here" syndrome: When company management becomes so dysfunctional they don't trust anything invented at their own company unless it's been externally validated.
One major thing not mentioned is that apprently not everyone bothered implementing FireWire the same. I never learned the technical reason, but if you bought certain digital audio recording interfaces circa 2007, you learned in the fine print/after you called customer service that it only worked with TI FireWire ports . These were the ones used on Macs at this point, I had a dell laptop which used a cheaper manufactu…
Note the recent problems where the Macbook Pro refuses to use Thunderbolt 3 devices with a TPS65982 chipset, and requires TI's TPS65983 chipset.
I'm not sure if Apple was the first company to do this; today everyone has wall chargers that output a single USB port, but I don't remember it existing before then. Hell, I'm not sure if there were any devices TO charge over USB when the iPod first came out -- those little SanDisk flash MP3 players, and I'm sure the bigger Archos hard-disk based MP3 players must have had their own chargers, there's no way they charged over USB.
I'm so happy that the world has gone in this direction, where I can use your Samsung USB charger to charge my Sony phone, or whatever. And Apple has still stick with the same charging brick style where you can flip out the prongs or use a longer cable. (not sure how it is now with USB C though).
But that firewire power brick still makes me nostalgic, a simple design that felt so elegant 15 years ago, and still does to this day.
I've used FireWire to connect external disks (verdict: as stable as eSATA, much better than USB2) and to pull video from a cable set-top-box (verdict: the cable box was crappy; no problems directly attributable to the FireWire connection.) The major problem with FireWire, shared with Thunderbolt, is that it offers DMA to external devices: https://en.wikipedia.org/wiki/DMA_attack
Doesn't USB-C have the same DMA problem? Did eSATA also lose to USB? I don't think it has the DMA problem.
Earlier quoted context omitted.
On the other hand, malware would have hit commodity devices much faster. That DMA is begging to be used to root a computer.
In that time period, most laptops had one or two PCMCIA/PC Card/CardBus slots that had the same vulnerability. They were commonly used back then to add modems, network adapters and even hard drives.
Earlier quoted context omitted.
Doesn't USB-C have the same DMA problem? Did eSATA also lose to USB? I don't think it has the DMA problem.
I think people with actual need for eSATA have moved on to PCIe SSDs. USB3 killed everything else at the low end; I remember buying an external HDD with FW800 in the olden days of 2011, then getting a USB3 drive in 2013 which is still going strong and fast (enough).
People that specifically needed their drives to be both fast and external moved to internal drives? I don't understand.
Earlier quoted context omitted.
I'm not sure I understand. Are you replacing hardware for clients who think they need low-latency realtime delivery of data, or for clients who actually need to hit low-latency delivery deadlines? From the article: > And FireWire had its own micro-controller, so it was unaffected by fluctuations in CPU load. This is still an important distinction for, say, an USB soundcard vs. a Firewire soundcard.
They need to get data in like... 3 seconds... So the operators can shut the machine down if something goes wrong. But now the machine has much more intelligence, so it shuts itself off quicker. And where they needed to check the "low latency" and "realtime" boxes in the 90s to get adequate performance, now any bus (like Ethernet, or you can stick Ethercat or Powerlink on top if you need realtime) is so much faster th…
That sounds like a not-necessarily-low-latency-yet-still-realtime problem for which the original low latency solution was replaced with a non-low-latency solution that still hit the realtime scheduling deadlines.
It seems as more and more big players put money into such solutions, the bonefide low-latency realtime problem space shrinks to a smaller mindshare. I'm not sure if that mindshare is fitting or insufficiently small, but the shift is palpable and does have drawbacks.
So if you know about the problem of receiving and sending audio fast enough so that the human on the other end doesn't hear the result as an echo, you read this article between the lines and go, "oh, that's what the microcontroller and isochrony are doing in there." If you're not, however, there's nothing explicitly stated in the article that informs the reader that this problem space still exists and can't be solved by throwing AI/4G/The Cloud at it.
One major thing not mentioned is that apprently not everyone bothered implementing FireWire the same. I never learned the technical reason, but if you bought certain digital audio recording interfaces circa 2007, you learned in the fine print/after you called customer service that it only worked with TI FireWire ports . These were the ones used on Macs at this point, I had a dell laptop which used a cheaper manufactu…
You didn't run into trouble with USB because by that time all your USB ports were coming straight from the Intel southbridge. Even if Intel's host controller implementation had issues, it would have been the device maker's problem to work around them since Intel's market share was so large.
No modern peripheral interconnect is simple enough for host interfaces to be judged on a mere pass/fail basis. The cheap chips almost always find a way to suck, whether it's obscure like FireWire or ubiquitous like gigabit Ethernet.
> Speeds across networks of all sizes are now so high that there's also little need for something like FireWire. "The packets can arrive way before it's needed, because it's so fast," Sirkin noted. "So you don't need to worry about being synchronous any more." For use cases where reliable low-latency transport is required (i.e., Firewire's main strength), what could possibly be meant by "packets arrive way before it'…
At least on Linux, you can easily be barraged by tons of IRQs from your FireWire device. Every time some data comes in from your device (let's say some music production platform) it's going to DMA that data right on over via a PCI lane or 4 then fire off an interrupt to inform your OS "hey hey got some new information for ya!". Now imagine the platform was poorly designed so it fires off that IRQ once for each track.…
57 resonant peak is at 200 Hz with steep rolloff below. It will sound like a bedroom recording no matter what you do with IRQs and DMAs.