|
|||
| By
Oliver Masciarotte |
|||
I say hopefully, because, as I mentioned in past columns, our upcoming advanced TV system is not without its problems, ignoring the fact that, at least in the short term, the audio and video quality will be worse than what we have now; ignoring another fact that if you live in an urban canyon as I do, then you may have to buy cable, because theres a good chance that over-the-air reception wont work. Right about this moment, youre thinking, Hey schmuck, this is an audio magazine! What DTV and this months continuing saga have in common is the i word: interoperability, or lack thereof. Technology, pulled in diverse directions by special interests, makes for a chimera that cant get up and walk out the door of your local consumer electronics retailer. Sorry to mix my metaphors, but, as I remind you all the time, its the consumer, stupid! Or rather, its the CE manufacturers and content holders that drive our audio industry. Like audio, as goes CE, so goes FireWire. Too Many Cooks?
The David among all these Goliaths is Digital Harmony (www. digitalharmony.com), a provider of tools, chip designs, software and product certification services. DH has come up with a bunch of stuff to address many of the issues facing a company wanting to mesh FireWire and audio. With a growing number of licensees, including Harman/Kardon, Lexicon, Madrigal Audio Labs, JBL, Infinity, Meridian Audio Group, Denon, Onkyo, Boston Acoustics, Panja and Sensory Science Corporation, as well as semiconductor partners Cirrus Logic, Crystal Semiconductors and ARM, Digital Harmony has a good deal of industry support. Right after the 1394 DevCon, I talked to the head honcho, Bob Moses, about his company. Their dream of all data formatsmultichannel and Red Book audio, MIDI, raw data files, even videobeing transferred over the 1394 bus without burdening the user with complicated format transcoding and synchronization decisions may come to pass. Moses is excited about the prospects of using FireWire in studios but also foresees potential problems. 1394s job really ends after youve moved a giant block of data from one device to another, he says. It defines the basic data transport services in a system, but not which audio and video formats or optional bus management services should be supported or how the equipment is controlled. This is left to developers to define, according to the intended application and require- ments of their products. There, my friend, is the rub. With such a wide-ranging standard, capable of handling isochronous data like audio, video and MIDI that requires guaranteed latency, as well as asynchronous data like IP, SCSI and other computer babel, theres bound to be some confusion and duplication when vendors get around to implementing this stuff at the application level. |
|||
|
|