8. What’s the real problem?

We discussed the issues with representatives from the codec developers—where our special thanks go to Michael Downs of Arcsoft for his helpful discussion of the subject matter—chipset makers—where we talked to representatives from Nvidia, ATI, and FreeScale, and attempted to contact Realtek and Intel as well—as well as the motherboard and adapter manufacturers.

In doing so, we began to understand that three potential solutions exist to the problems inherent in uniting audio and video. But while meeting digital copy protection requirements may be possible following any of these approaches, none of them has been sufficiently standardized or proffered as a sufficiently complete technology to permit viable commercial implementations to hit the market. Of course, this also involves the need for protected audio path (PAP) driver technologies from Microsoft, along with driver certification and testing tools and regimes, none of which is available yet either.

These three possibilities are as follows:

• The Complete AV Interface

  : This approach involves integrating DSPs and audio chipsets, along with video circuitry, onto a single adapter card that handles both high-definition video and high-bandwidth audio in one hardware module. We’ve heard reports that experimental implementations of such architectures are underway at Nvidia, ATI/AMD and Intel, as well as at some of the motherboard manufacturers. This solution has the advantage of requiring no interface to unit audio and video data, but would probably be the most costly single-source technology solution. It would include a single HDMI 1.3-capable output connection to ferry high-definition audio and video out of the PC.

There are those who might argue that products like the GeForce 8200 and 780G chipsets—which bring an audio chipset into the GPU, and are intended to permit 7.1 LPCM and video to leave the motherboard via the same HDMI port—and graphics cards in the NVidia 84xx, 86xx, and 96xx or Radeon HD 2x00 and 3x00 series, represent a first step in this direction; and they’d be right. But at present, they emit only two-channel LPCM, and won’t bitstream the high-bandwidth Dolby and DTS formats. As for upcoming Radeon 4x00 circuitry, we speculate on its capabilities later in this story.

• PCI-e Bus Interface

  : Audio adds only negligible additional bandwidth requirements to those needed for HD video—even 30-plus Mbps for uncompressed 8 channel 192 KHz 24 bit sound doesn’t add much to video bitrates, nor add much stress to the PCI-e bus. Given that, if a standard AV interface existed that permitted transmission and merging of audio and video bitstreams for output, it would probably already be in use. Given the wide availability of DSPs for audio and complex, and competent graphics chipsets for video, we could even hope that firmware upgrades alone might suffice to make this possible. This would bring audio and video together across the bus for output via a single HDMI 1.3-capable connection.

• High-def Audio Bridge Pinouts

  : Look at this as a different method for achieving what the preceding option delivers, subject to the idea that if a simple standard pinout worked to enable internal SPDIF bridge cables, the same technique should suffice to create a more complex, higher pinout standard for high-bandwidth audio. If scaling is linear, given that 4 pins gets us 1.5 Mbps with SPDIF, this might mean we could see a 16 to 32 pin header for high-def audio to support even the highest bandwidths for DTS-HD Master Audio. This would then enable users to cable audio and video processing chains together for output via a single HDMI 1.3-capable connection.

Michael Downs, VP of Marketing and Business Development at ArcSoft (maker of Total Media Theatre, one of the “big three” Blu-ray Disc decoding programs) also had this to say about a key Microsoft API known as the Protected Audio Path, or PAP (see Output Content Protection and Windows Vista for a pointer to a white paper that touches on this topic). “Keeping the audio stream secure through the hardware/software system is done through MS Protected Audio Path (PAP) driver specifications. Without MS standard software interfaces, all hardware and software companies would have to have work with many different, proprietary driver interfaces. For video on XP, we have all worked with proprietary software APIs for AACP and HDCP. For WinXP it is unclear how support for full high-def audio will be implemented. For WinVista, the plan is to use MS PAP in the future. The status for MS certification of drivers is unclear.”

As you can see on the MS Web page cited above, Microsoft indicates that the “Protected Audio Path (PAP) is a future initiative under investigation for how to provide encryption of audio over user accessible buses.” Thus, according to Downs, “the PAP specifications are still subject to some interpretation at this stage of driver and software development.” In other words, even the view from Microsoft’s perspective about how to deal with high-def audio remains somewhat murky.

Thus, the real problem—at least in our opinion—is the lack of an apparent or obvious agreement about how to proceed here, and the subsequent definition of a standard to make workable PC implementations possible (and hopefully, affordable). We can only hope that efforts underway at various firms with a vested interest in the success of high-definition PC video and audio, especially as it pertains to Blu-ray playback, will result in the release of workable technology solutions to the marketplace.