ATI Radeon HD 4600 & 4800 series support 7.1 channel HDMI audio!

A Licensed Player shall not pass, or direct to be passed Decrypted AACS Content to a digital output except:
1.4.1 A digital output of audio, or of the audio portion of other forms of Decrypted AACS Content, in compressed audio format (such as AC3) or in Linear PCM format in which the transmitted information is sampled at no more than 48 kHz and no more than 16 bits.
1.4.2 An output delineated in Table D1, AACS Authorized Digital Outputs, in accordance with any associated restrictions and obligations specified
therein;

When asked why PowerDVD downsamples HD audio from both Blu-ray and HD DVD discs to 48KHz / 16-bit, Chen responded by saying that "digital output without protection is not possible due to AACS requirement. Digital and analogue output with protection (HDMI) is also not possible due to lack of an internal secure audio path in a Windows PC."

"We are currently working with Realtek to support their proprietary interface for encryption of audio bus. Once completed, we will not longer need to downsample the audio. This will be provided for free to end-user for upgrade."

This didn't really clear up the downsampling situation though because, as far as we're aware all audio, regardless of encryption, is downsampled. We therefore pressed Chen to clear up the speculation. "I think this is a mistake," he said, "we never intended to pass this message. I think there might be some bug in our program that downsamples everything. That is not our intent. We only need to down-sample premium content (AACS, CPRM, etc)."

This prompted us to ask whether there is a requirement for AACS in a PC when a disc or file is not encrypted. Chen told us that the unencrypted scenario is not mandated by AACS so shouldn't be included in the downsampling.

We inquired further about the "secure internal audio path": is this because of Microsoft not providing one and/or sound card companies not providing a compatible driver? Chen informed us that there isn't an industry standard (defined by Microsoft or someone else) that makes the encryption/decryption path between software and audio driver secure. CyberLink have to enable one chip after another which takes a considerable amount of time working with sound card providers, Microsoft and checking that it satisfies the AACS mandate.

The lossless audio support that we first covered a while back has been put back to the release of 8.5 at around the August-September time frame. Again, CyberLink was keen to stress that this will be a free update if you already own PowerDVD 8.

This delay can be significant issue for those wanting to use PowerDVD 8 with Blu-ray disks, but after discussing this with both Dolby (TrueHD) and CyberLink, as well as various motherboard vendors (Gigabyte boards that use the Realtek ALC889a and features “content protection”) and even AMD (in reference to its 780G and its audio limitation to S/PDIF pass-through under HDMI) during CeBIT, all we can conclude is that HDCP for full quality audio is just a complete mess.

Another thing worth noting though is that PowerDVD 9 (formerly 8.5) will be available in a Q3 to Q4 timeframe this year

4 Protected User Mode Audio: PUMA

4.3 PUMA (Protected User Mode Audio) Security Architecture

This section examines the components in the PUMA engine concerned with security.

Aside from the Virtual Audio Server (VAS) receiving component, the PUMA architecture includes three protection-related component types of interest:

• Virtual Protected Output (VPO) module
• Protected Output Controller (POC)
• Output Encryption Audio Processing Object (APO)

4.3.2 Output Encryption APO

The Output Encryption APO is the module that will provide encryption of the audio data, if it becomes necessary in the future. For the initial release of Windows Vista, it is planned that just the interfaces to the module will exist, rather than any actual modules.

The planned implementation is that the audio system will request an Output Encryption APO from the POC. The audio policy will set up the audio engine such that the Output Encryption APO will be called as the last processing element for the audio data, before the data is passed to the driver. This allows the Output Encryption APO to encrypt the data according to the current protection policy. The POC will choose to not load an Output Encryption APO if encryption is not necessary (which it isn’t in 2006).

4.7 PCIe Bus and PUMA

In the same way as with video, the PCIe bus could become a problem for premium audio, because content owners might regard it as a user-accessible bus. The issue affects the use of a discrete audio card or a discrete graphics card that has audio capabilities. While there might not be many discrete audio cards in 2006, there more than likely will be HDMI discrete graphics cards that have HD Audio controllers.

The important scenario is the play back of HD-DVDs and Blu-Ray DVDs. In this case, the video is considered premium and the audio may also be. There is no problem with the video, because PVP-UAB (Protected Video Path - User Accessible Bus) protects the video over the PCIe bus, but there is currently no equivalent protection available in the audio world.

The PCIe bus may be defined in some Content Industry Agreements as a user accessible bus. It is further defined in some Content Industry Agreements that premium audio is not allowed to pass over a user-accessible bus in unprotected form. In spite of PC industry push-back on this requirement, it is not certain which way the decision will fall. Realistically, any concession in this area would only be valid for a small number of years, so the PC industry needs to address this issue in the not-too-distant future. Microsoft plans to address this as part of the PAP (Protected Audio Path) project that will be a number of years after the initial release of Windows Vista.

When the PC industry does PAP, there will be a way of encrypting audio over the PCIe bus. For discrete graphics manufacturers, the easiest mechanism to use would be PVP, because their graphics chip hardware will already be able to decrypt this. The encryption would be done in an Output Encryption APO module in the Audio Engine in the Protected Environment.

As mentioned earlier, the plan is to provide a mechanism in Windows Vista to load a future Output Encryption APO module. Even in the initial version of Windows Vista, however, a third party could write a custom Output Encryption APO module that performs PVP encryption. This would need to establish a separate session key, because there is no robust way of getting the session key from the graphics stack to the audio stack.

We hope to be successful with the amendment to the content industry agreements, so that using an encrypting Output Encryption APO module can be deferred for a few years.

5 Protected Audio Path: PAP

Possible PAP Architecture

Think about PAP is as a collection bucket where we store future ideas about audio content protection. Current thinking is that PAP would provide protection all the way to the codec chip that has the digital-to-analog converter that makes the sounds (*my comment: replace it by HDMI transmitter). This might include protecting over whatever physical and wireless cables are in use in that future timeframe.

The most likely encryption candidate would be AES 128-bit counter mode, just like PVP. Instead of the ProtectedDXVA component doing the encryption, the encryption would be done in an Output Encryption APO in PUMA. In both the audio and video cases, the important thing is that the encryption is done inside the Protected Environment.

The proposed plan is that the hardware AES engine that does the decryption would be in the codec chip. This is a harder than in the case of a graphics chip, because codecs have far fewer gates and are also more price sensitive. The desire to not over burden codec chips is a contributing factor in not pushing to introduce audio encryption quickly. Adding AES engines to codec chips would at best take many years, and might turn out not to be feasible. (*For discrete graphics manufacturers, the easiest mechanism to use would be PVP, because their graphics chip hardware will already be able to decrypt this.)

Establishing a session key is the hardest problem. It is not practical for an audio codec chip to do Diffie Hellman, because there is no natural math capability as there is in the case of graphics chip programmable shaders.

Providing robust hardware authentication is a big part of what PAP is about. As in the case of PVP, HFS (*Hardware Functionality Scan) can be used for hardware authentication. A codec chip is not as complex as a graphics chip, but even so there is enough sophistication that can be used in the HFS process. For PAP, the authentication would likely be done using a codec-specific user-mode authentication module that would plug into the POC component in the PUMA engine. Even though the user-mode module would be specific to a particular hardware manufacturer, the Microsoft class driver can still be used.

That still leaves the problem of how to establish a session key. Tentative plans address how to extend the HFS process to also generate a key at both ends of the wire. For want of a better name, this process is called MKey. The session key established between the Output Encryption APO and the audio codec chip would be used to encrypt a content key generated by the Output Encryption APO. It is the content key that the Output Encryption APO would use to encrypt the content.

As stated, the requirement to encrypt audio data is still many years away, and there is certainly no specification for how to do this yet. Having said that, Microsoft is eager to work with manufacturers of codec chips to plan for the future.

ASUS, with assistance from C-Media and ArcSoft, has been able to adhere to the PAPS and AACS content schemes without having to downmix the audio sources (resulting in 16-bit/48kHz DVD quality audio) or even dropping support for DTS-HD and Dolby TrueHD altogether.