This (Firewire chipset) problem has been around for over a year and yet the geniuses at Apple haven't figured out the simple solution -- use the TI chipset, the one that's known throughout the audio world as the chipset that works with most audio devices.
That's putting the horse before the cart, though. The TI chipset's other disadvantages are obviously not worth it on balance, or it would have been selected by everyone. The problem of intermittently not working with audio hardware, particularly when the workaround is so simple, is not compelling and
not their problem if the audio manufacturers can't implement hardware that is fully compliant. Frustrating, yes, but as you say, these are not new problems with real-time audio (yet real-time video hardware has largely managed to figure it out).
But yes. All the people who who've never done anything in audio always want to place the blame on something or someone else (other than the computer or chipset manufacturer) and they always express their amazement that a hard drive can copy files fine but a audio device can't work in real time.
Again, the problem isn't with real-time data transfers, because video and other dedicated data transfer hardware works fine. The problem is in audio hardware manufacturers refusing to deal with the known limitations and design around them. As far as 1394 is concerned on the destination peer end, it's
real-time data and it works perfectly fine. If
audio is the problem, then the
audio devices are the problem.
The question is why certain chipsets work with certain audio controllers, and the reason is simple: because the audio people design to the chipset, rather than to the standard (because it is cheaper and easier), and then post FAQs about which chipset you should use with that particular device. That's perfectly valid, but you can't then blame other companies when they elect not to use that chipset, because their decision is equally valid.
This is a perfect example of the sorts of problems that can occur that rarely get solved because the self proclaimed "experts" aren't willing to listen to the people who've been using (or manufacturing) the equipment for decades.
The audio manufacturers have an opportunity to participate in the engineering of the standard. They have an opportunity to create their own standard interface. They have the opportunity to design around the problem.
This particular incompatibility is not inherent to audio transfers; data is data on the 1394 bus. It's solely about Firewire implementation, and "audio people" have the power to solve it. Again, it's as trivial as putting another FW device in between the two, so it's not some critical performance issue that the audio manufacturers can't deal with. And once again, I see no evidence that suggests that the Agere chipset is materially defective or not compliant with the standard.
You continually suggest that it is not the audio manufacturer's fault, when all signs indicate it is more likely that it
is. I do a great deal of work with standards bodies and parties accusing each other of implementation failures, and your story simply doesn't add up. The compatibility issues are indeed well-known, but it's the audio industry that seems unwilling to do anything about it. I have yet to see a plausible explanation for why real-time audio is plagued at a much greater rate than real-time video that implicates Firewire hardware itself as the culprit.