Why then are home theater PC folks so obsessed with playing back at a paltry 24 frames per second when graphics solutions (including integrated graphics) are easily able to send out 60?

Judder-bug

Okay, so it's not an actual bug, it's just a bad pun. But the key is the word "judder". To understand why it matters, we must understand how films are made.

Motion pictures in 99% of Hollywood cinema are recorded at 24 frames per second and then each frame is strobed twice before the next frame is indexed. In effect, film in theaters is displayed at 48Hz, though the actual content is 24Hz.

Historically speaking, TVs are 60Hz (to match the AC frequency of the wall socket; in other countries with different wall socket frequencies, the TV rate is different). While I won't get into the specifics or the full history here (there are lots of sites out there which cover why this was so and how it was compensated), the major understanding to carry forth is that in order to get 24 frames of content into something that is refreshed 60 times per second, you have to repeat frames in an irregular way.

In short, the first frame in every second is repeated 3 times, the second frame is repeated 2 times, the third frame is repeated 3 times, the fourth is repeated 2 times, etc. This process is known as "3:2 pulldown", and you can see from the math that if you repeat 12 frames 3 times each and 12 more frames 2 times each, you will get 60.

So all of the picture content makes it onto the television screen, so everything's great, right? Alas, the human eye is only partially fooled: on scenes with high amounts of motion or where the camera pans across a landscape, the phenomenon known as "judder" manifests. The motion should be smooth, but you can see some jerkiness to it due to the fact that every other film frame is of slightly different duration.

This isn't a new problem: film has been 24fps for a long time, and TV has been 60Hz for almost as long. When TVs were interlaced the issue was reduced because at the transition between the 3-frame and the 2-frame the middle frame was essentially a mix of the two (again, not going into the specifics on interlacing history). Nowadays, TVs are made with non-interlaced (aka "progressive") components and you can see the judder artifacts better.

There are ways around this; people with computer monitors have a bit more flexibility with their refresh rates than TV users traditionally do. Setting the graphics to output at 72Hz generates a nice image (since 72 is an even multiple of 24), but the vast majority of television sets won't accept 72Hz signals. And while there are some computer monitors you could reasonably call "home theater worthy", most are a bit small and limited.

As I mentioned, this is not a new issue, but until now most sources were interlaced (even DVDs are generally interlaced, though flags in their software exist so progressive player hardware can pick out the original frames) so the issue wasn't high profile. With new technology like Blu-ray, the video is stored as 24 actual pictures per second, and the only limiter left is the display.

Of course, when you're a Consumer Electronics manufacturer, any nifty gadget you can add to your TV to distinguish yourself from your competition is a good one, and someone got the bright idea to include inputs which would accept and display 24fps. Everyone else soon followed, and now a lot of mid- to high-end equipment has the ability to take in images at 24fps and display it at some multiple of that (technology in the generic TV set has changed enough to decouple it from the original 60Hz number).

What the heck is your point, Brezenski? What does this have to do with Intel graphics?

Glad you asked. Early drivers for the 945G, G965, G33, and G35 were all capable of 24Hz output. You had to play tricks on them sometimes to convince them they could do a resolution/refresh they didn't know about by default, but if you got the drivers to accept that they could do it the chipset graphics would deliver 24fps goodness. After all, theoretically in sheer processing power it should be easier than the normal 60fps; any integrated graphics chip should be able to do it.

In reality, there were some difficulties, and they remain today. Desktop work at 24fps was fine, but watching media at 24fps exhibited very jerky behavior every several seconds or so... then returned to silky smooth motion once more. This was across a variety of software players-- both free and consumer-- and across multiple motherboards and chipsets. And didn't manifest on either ATI or Nvidia graphics... suggesting, once more, that this was a problem with the drivers. (It's vaguely possible this is a hardware issue with the chipsets, whose design concentration would logically have been "ensure high refresh rates".) There was some sign this might be modulated by the renderer used (EVR vs VMR) as well as by the presence of extra frames in the source files, but as of the 15.7 drivers there manifested a new problem: all support for 24fps is gone.

Whether your EDID is advertising the 24fps capability or not, even if you use the trick I linked to above, the resolution won't show up as selectable in the Intel drivers. 48Hz still seems to work fine... but as there are only a handful of TVs which accept 48Hz signalling, this is small consolation.

It could be that someone on the driver team recognized that 24fps was broken and removed it, or there could be something else going on that's even more mysterious. It could entirely be an oversight. But the fact is, even if you want jerky 24fps on Intel graphics you now have to use older drivers, keeping yourself in the past and avoiding fixes you might want for other bugs.

I haven't gotten my hands on a G45 system yet, so I don't know if this issue is fixed on newer graphics chipsets yet, but I sure hope so.

If you ask around in the home theater PC community, there are three issues which prevent Intel graphics from being an all-around winning solution for HTPCs:

1) The HDCP repeater bug

2) The 24fps problems

3) The Denon HDMI EDID issue

You'll note that these three issues just happen to be the ones I've covered in my blog. This is not coincidence.

I've seen internal presentations, and if our drivers meet or exceed the hardware the G45 is going to be a great chipset from a home theater standpoint. But it's important that we address the enthusiast in this space (because the enthusiast is going to tell his friends what to buy) and the enthusiast sees all three of those issues as important to have solved in a quality system.

So far I've not noticed a driver release which fixes any one of them. I don't know that any of our Graphics (or Audio) folks read this blog, but I sure hope so.

P.S. I won't even discuss the fact that it should really be 23.976fps instead of exactly 24fps. You'll have to figure that one out on your own. :)

I've already discussed the benefits to Intel Graphics and HDMI Audio in a previous post, and complained about the HDCP repeater mode bug (still unresolved as of graphics driver release 15.9.2) which forces people to use gray-market software if they want to use Intel HDMI Audio to play Blu-ray disks with a receiver, but there's still one more nit I have to pick: there is a very prominent, mid- to high-end consumer electronics supplier whose receivers are still not playing ball with Intel HDMI Audio. Let's explore why this is, and-- at least philosophically-- how I think this should be fixed.

What Can Your Receiver Do?

With HDMI, we finally have a two-way path for communication between the source and endpoint devices in the consumer electronics space. This means a lot for the Digital Rights Management crowd, but it also enables something pretty cool for end customers in general: a source device can query the end device and tailor its output to the best possible the endpoint device can produce.

Computer monitors have been doing this over VGA for years, and later over DVI. There is, in fact, a special data structure called the EDID (Extended Display Identification Data). The source sends a command to the monitor/television to send its EDID, and the monitor/television responds with a 128-byte message which details the native resolution of the screen, any specific timings it likes best, etc.

For HDMI, this structure has been extended further with another 128-bytes. These bytes supply more specific timings and, most relevant to our discussion here, a list of which audio possibilities the end device supports. In the normal case of a TV as the end device, the report back is typically "LPCM 2.0" (lossless stereo sound) or at best "Dolby Digital 5.1" (five channel lossy compressed sound). When you place a nifty new audio receiver in the signal path (as an HDMI "repeater"), however, the receiver itself intercepts the TV's EDID and adds its own information before sending it back to the source device (DVD player or Blu-ray player or PC). The specifics of how this is done are discussed in the consumer electronics spec CEA/EIA-861D, and summarized in the EDID Wikipedia article.

Theoretically, this should allow the source device (in this case, the PC) to send the best possible audio your TV or receiver can decode. Simple, right?

How Does Your PC Handle It?

Let's ignore the graphics case, for now; I can (and eventually will) write an entire article about the lies EDID can tell about TV/monitor resolutions. As ever, let's hit audio.

As discussed in a previous post, Intel's HDMI Audio solution is a bizarre intersection between Intel HD Audio (aka The Artist Formerly Known as "Azalia") and Intel's SDVO video. The interactions between the operating system (using Microsoft's Unified Audio Architecture or UAA) and the Intel HD Audio hub in the southbridge are complex enough before you add HDMI. Suffice it to say that, in a roundabout way, the operating system asks the audio subsystem what it can do so it knows how to send any sounds without something screechy and horrible erupting from your speakers.

Taking this further, in order to report this back to the OS, Intel's HDMI Audio needs to get the ELD (or "EDID-Like Data") from the end device. It does this by... you guessed it... querying the connected device(s) for EDID.

So the path in a typical configuration is:

OS --> (query for capabilities) --> HD Audio Bus --> HDMI Audio chip --> (query for ELD) --> Graphics drivers --> (query for Receiver EDID) --> Receiver --> (query for TV EDID) --> TV

The TV gets the query, reports back what it can do, the receiver adds on its own capabilities, and the answer cascades back to the OS, which reveals in some Audio Properties window what the HDMI Audio is permitted to send to the downstream devices. 

Slightly insane, and with this many players you can see the potential for software or firmware breakdown. Needless to say, in order to protect you (and Microsoft's legal department) from sound which will rupture your expensive speakers, the OS will not send sound in any format that the HDMI audio chip does not explicitly state it supports. Therefore, the UAA driver in the OS, the HD Audio Bus driver, the HDMI audio driver, the graphics driver, the receiver firmware, and the TV's firmware are all links in a chain which can mess up the audio capabilities.

In this case, again, we must focus. Pretty much everything in this path works, miraculously enough, but there is one corner case that does not, and it's an ugly one.  Denon is a very popular brand of AV receiver-- especially in the demographic that is currently messing around with HDMI audio: the early adopters and the audiophiles. Hooking up a sparkling new Denon 7.1 channel receiver to your nifty Intel HDMI audio solution will net you... 2 channel stereo. Same as most TV sets. Other receivers (Onkyo, Yamaha, etc.) don't have this difficulty.

Where in the signal path is the problem?

Ambiguous Specs and Ambiguous Drivers

The problem, after much debug by myself and some second level folks in our support group, is that Denon is doing things differently in their EDID than other consumer electronics manufacturers, and the way Intel drivers are handling this is not helping.

Which puts it somewhere in here:

HDMI Audio chip --> (query for ELD) --> Graphics drivers --> (query for Receiver EDID) --> Receiver

Per spec, the audio data in the EDID is found in one or more Short Audio Descriptors ("SADs"). The way most manufacturers do this is to have a single "tag" byte followed by a number of SADs. For instance, an Onkyo receiver enumerates its audio with

38 09 7f 07 0f 7f 07 17 07 50 3f 06 c0 4d 02 00 57 06 00 5f 7e 01 67 7e 00  

 The "tag" byte tells how many bytes follow which are SAD data (in this case, 24), and the remaining bytes are three-byte SADs which detail stuff like which formats are supported (like Dolby Digital, DTS, LPCM, WMA Pro, MLP), which bit rate and depth they are supported at, and how many channels can be played back. In this case the Onkyo parses out as:

LPCM 2 Channel Sound, Frequencies:192kHz, 176kHz, 96kHz, 88kHz, 48kHz, 44kHz, 32kHz, Bit Depth :24 bit, 20 bit, 16 bit
LPCM 8 Channel Sound, Frequencies:192kHz, 176kHz, 96kHz, 88kHz, 48kHz, 44kHz, 32kHz, Bit Depth :24 bit, 20 bit, 16 bit
AC-3  8 Channel Sound, Frequencies:48kHz, 44kHz, 32kHz, Max bitrate :640
DTS 8 Channel Sound, Frequencies:48kHz, 44kHz, Max bitrate :1536
SACD 6 channel Audio
Dolby Digital+ 8 Channel Sound
DTS-HD 8 Channel Sound
MLP/Dolby TrueHD 8 Channel Sound

What happens with Denon? Denon takes a slightly different approach. Denon precedes each SAD with a "tag" byte:

23 0d 1f 07 23 09 7f 07 23 3d 1f c0 23 15 1f 51  

Note the recurring "23".  That's "This Audio block has 3 bytes (1 SAD)".   The first one is 8 channel LPCM, the second is 2 channel LPCM, the third is 6 channel DTS, and the fourth is 6 channel AC-3.

Herein lies the problem. Intel audio drivers sample the ELD and see the first Audio block has an LPCM value of 8 channel capabilities and are thrilled to offer this... then they keep reading and see there is a completely new Audio block, with a new set of SADs.  This second Audio block has a SAD with an LPCM value of 2 channels... which overwrites the 8-channel value. Oops. Now the drivers report back that the receiver can only do 2 channels and the OS will not even offer 7.1 channel LPCM as an option. Wouldn't want to frighten the Denon with sound it can't handle, after all.

At this point, I am uncertain whether the error gets made at the HDMI audio driver level or the Intel Graphics driver level-- does the Graphics driver parse the EDID and pass along the ELD with 2 channel values, or does the Graphics driver send the entire EDID and the Audio driver overwrites the 8 channel values with 2 channel all on its own? No idea. But Intel's system does not cope well with Denon's "special" way of doing things.

Now, as for that "special way"... it's unconventional-- no one else does it this way-- and it's wasteful of bytes... but is it against spec?

Here's where strict adherence to a crappily-written spec can (and in this case, does) get Intel and Denon into trouble: CEA/EIA-861B states

"The format of the "CEA Data Block Collection" shall conform to that shown in Table 30."

I'm sure it would be a violation of copyright restrictions to include Table 30 here, but please trust me when I say it looks exactly like the Onkyo example above: single "tag" byte, followed by a stream of three-digit SADs.

But wait... in the exact same paragraph:

"Note that the order of the Data Blocks is not constrained. It is also possible to have more than one of a specific type of data block if necessary to include all of the descriptors needed to describe the DTV Monitor’s capabilities."

So... Denon is providing more than one of a specific type of data block (Audio). They don't have to all be in one stream, per this interpretation.

And so the argument extends. Denon sees nothing wrong with their interpretation. Intel says Denon should fix their EDID.

Intel can point to what is arguably their accurate reading of the spec (I tend to read it this way, as well); Denon can point to the fact that HD DVD and Blu-ray players, the PS3, and other devices don't seem to be having difficulties streaming 8-channel sound to Denon receivers... why should they have to distribute new firmware to all the owners of their receivers... why is this their problem again?

The irony is: if Denon had chosen to write LPCM 2 channel first and LPCM 8 channel second, everything would still have worked and we'd never have known about the problem.  

Does It Matter?

Ultimately, the consumer doesn't care who's right or wrong in this esoteric technical dispute. They plug an Intel computer into a Denon receiver and it only gives them stereo. They swear at it for a bit, plug in their friend's PS3, and it works fine with 7.1 channels. Do you think they consider it important whether Intel's or Denon's reading of the spec is right?

Of course not.  The PS3 and other consumer electronics devices are at best simply ignoring the problem; at worst, they are aware and don't care-- they'd rather have their device be transparent to the consumer than argue the intricacies of specs.

It is my firm belief that Intel should relax its read of the audio bytes of the EDID to accomodate what is arguably an ambiguity in the spec purely to satisfy customers. I don't know if it's our Graphics driver or our Audio driver, but it should be able to cope with Stupid EDID Tricks.

Yes, Denon is probably at fault. I'm with you driver guys, and will drink a beer with you to commiserate. But in the end-- at least in this matter-- fault isn't important. Results are, and we need to show that our solution works on as much equipment as possible.

Right now we're being stubborn on something that doesn't really matter to us, but matters a whole heck of a lot to the end user.

Which is most important?

I won't go too deep into the history of HDMI and HDCP in PCs; I'll just summarize and say that early HDMI-enabled graphics cards from our competition were missing HDCP protection, and there were threats of lawsuits because they originally advertised their chips (not the actual end-user cards, mind you, their chips) as "HDCP-ready".

Though Intel was comparatively late to the game on HDMI, as far back as the 945G we supported HDMI through the use of conversion chips from our partners. These chips sit on the SDVO bus (as I've mentioned earlier, this is an interface which is muxed into PCIe from our northbridge) and convert the SDVO video into the HDMI signalling protocol.

Keep in mind that when the SDVO-HDMI chips (most common are the Chrontel 7315 and the Silicon Image 1390) were being designed, the released HDMI spec was at 1.0, and much of the audio portion of the 1.1 spec (which added a lot of audio capabilities) was still a work in progress.

I don't know which individual at Intel is responsible for deciding to ask the SDVO chip vendors to include an Azalia (aka Intel HD Audio) interface on the SDVO chip, but I hope that person got lots of stock options. It was an idea ahead of its time, risky, and although it was ultimately flawed due to content protection issues which arose after the design had already been finalized, it currently still provides Intel with a competitive advantage:

For the past two years, only Intel's HDMI audio has had 7.1 channels of lossless, high-def sound.

I write this on April 25, 2008, and that advantage is barely publicized but already falling away.

What happened?

Technical History

Speculating on what goes on in the conference rooms of our competitors is ultimately a fruitless exercise, but one could guess that, being graphics companies, they simply de-prioritized the audio portions of HDMI in favor of the video. Went with the part they understood best, in other words.

I can sympathize-- I'm alternately suprised and impressed that we didn't make the same mistake.

Some technical discussion is in order. HDMI was designed as a single-cable solution for audio and video. The video passes in much the same way it has on older interfaces like DVI and VGA: draw a screen line by line, finish the screen, wait an instant, and then start drawing the next screen; do this 50 or 60 times per second. In HDMI, the "wait an instant" portion of the time (known as the "blanking interval" by video nerds) is actually long enough to pass a significant amount of data, and it's referred to as the Data Island.

The HDMI spec allows the Data Island to be stuffed with all sorts of things, but germane to this discussion is that as of HDMI 1.1 it can be filled with audio packets.

All sorts of audio packets. A typical CD player puts out digital audio in a format called Linear Pulse Code Modulation (LPCM): up to 2 channels worth of data at 16 bit resolution and 44.1kHz sampling frequency. That's allowed over HDMI. A DVD player can put out 2 channels of LPCM at 24 bit resolution and 96kHz sampling frequency. HDMI permits this, too. DVD players can also put out 6-channel lossy compressed sound in the form of Dolby Digital or DTS. HDMI is pleased to offer this service as well.

Of course, you can get all this over the old S/PDIF protocol (the optical or coaxial digital cable which comes out of a DVD player and goes into a receiver or TV), and lots of people do. The real benefit to HDMI audio is the ability to transfer massively more sound data than S/PDIF was designed for.

With HDMI 1.1, you can send 8 channels of lossless, uncompressed sound in the form of LPCM at up to 24bit resolution and 192kHz sampling rate. Even those crazed audiophiles who think the sound of old vinyl records still beats the digitized CD versions concede that at that resolution and sampling rate there is no way for the human ear to distinguish the recording from analog. It's the Holy Grail of multichannel audio, essentially equivalent or better than the studio masters used to make the film prints that go to theaters.

It's nice, and it's only in the past three years or so that there have been HDMI receivers available which can actually process that level of sound; prior to that, high-definition multichannel sound had to be converted to analog and sent to the receiver that way. That worked, but the quality of the result was always limited by the Digital-to-Analog Converters (DACs) which convert high-def sound data to analog signals-- and the DACs in most motherboard solutions are passable but not great. With an HDMI solution, the data is sent digitally and the receiver's DACs are used, and generally speaking the DACs found in an A/V receiver are going to be significantly better than ones chosen by a motherboard vendor trying to save a buck or two. (I'm not criticizing... that's just the difference between business models for the two industries.)

HDMI, then, is really the most efficient way to pass high-end multichannel audio from the PC to the receiver. As mentioned before, older digital methods like SPDIF are limited to 2 channels or compressed 6-channel sound which (though it typically sounds very good) loses something in the translation. It's the interface of choice for those who want to take advantage of high-resolution >2 channel sound formats found on DVD-Audio, HD DVD, and Blu-ray disks.

The Ball: Dropped

Despite the fact that HDMI 1.1 (and greater) have been spec'd out for several years, video cards have, at best, provided SPDIF-level sound. A good part of this may be the focus of their business (video rather than audio), and another part of it is the "who cares?" factor: SPDIF audio is good enough for most people. Humans are very visually oriented in general, and it's far easier to notice compression artifacts in an MPEG2 image than it is to notice the equivalent in a Dolby Digital soundtrack. That doesn't mean the audio artifacts are not there, annoying those that can hear them, but it's evident to those in the industry that high-quality is not the highest goal of most PC listeners: MP3s, flawed as they may be, are way more popular than high-def audio like DVD-Audio or Sony's SACD formats.

But that doesn't mean the market for a high-def audio solution does not exist, just that it's a niche market. You'd think the sound card folks would have stepped in, right? That is their business, after all. Alas, no; the HDMI spec assumes you're sending video along with the audio, and evidently the sound card makers decided it was not worth the bother.

So: HDMI is the best way to transmit high-definition audio, but video card makers-- even when they do send the audio-- don't support the high-def specs and audio card makers by and large just aren't playing along.

Enter the Intel solution. Late to the HDMI game, and only on motherboards (no discrete cards yet), Intel piggybacked its HDMI implementation on the pre-existing Intel HD Audio functionality by hooking the SDVO chips into the HD Audio bus on the motherboard as just another codec. (For those not familiar with Azalia-speak, essentially the SDVO-HDMI chip is recognized as just an extra sound device to write to-- just like a Realtek or Sigmatel or other normal audio chip found on the motherboard.)

There have been bugs (and still are: the repeater mode bug I mentioned in my previous post is one of two serious ones) but to a pretty good approximation It Just Works. It may sound hard to believe, but a not insignificant number of HTPC people are buying Intel integrated graphics solutions for this reason alone-- full resolution 6- and 8-channel audio simply cannot be passed digitally in any other way than on certain specific Intel platforms.

That's a win, but it's been a pretty quiet one. I've been crowing about it among the enthusiast crowd as soon ever since I figured it out (the functionality is buried in our graphics drivers and not exactly obvious unless you know what you're looking for) and it's pretty well known now in those circles, but I haven't seen Intel as a company using it for bragging rights.

Given some of the other stuff we do brag about, I'll admit this is a bit mysterious to me, but I'll chalk it up to internal ignorance: even our own customer support folks don't seem to know the functionality is there and in some cases don't believe our customers when they're asked to provide assistance. The sound chip drivers are, after all, the responsibility of Realtek or Sigmatel-- that's what we've been instructing customer support to say for years-- and Intel doesn't offer assistance for those. The end-user must be mistaken when he or she claims that there's an Intel-generated and -supported HDMI Audio driver, right?

Bottom line: excellent implementation, kudos to the Intel HDMI Audio driver team. Poor publication. I'm sure when it debuted in the 945G timeframe there was little to crow about-- you could barely even find a receiver which could accept the audio over HDMI, then. But once HD DVD (RIP) and Blu-ray came out and the G965 was capable of playing them, I think we probably should have started evangelizing our solution more in the press.

"The only way to get the full audio you deserve." Or something like that. See, there's a reason I'm not in Marketing.

The Future

I mentioned before that our lead here is going away; it seems at least one of our competitors is finally claiming to supply the same full audio capabilities over HDMI on its latest motherboard chipset. The functionality is still not working in their drivers, which is why I say "claiming", but let's be conservative and assume it's only a matter of time. We can only assume that our other competitor will follow sooner rather than later.

Advantage lost, apparently.  :(  Are there ways we can still provide added value in this space?

The answer is yes, but time is of the essence, because dollars to donuts the competition is working on this, too.

The HDMI spec has been revised twice since the initial 8-channel LPCM capability was added. Rev 1.2 added support for natively passing DVD-A and SACD streams without decoding them into LPCM first, and Rev 1.3 added support for natively passing the new high-def lossless formats (Dolby TrueHD and DTS HD Master Audio) used in Blu-ray. Any player worth its salt can already decode these new formats into LPCM, so why bother sending the original bitstream instead?

The answer lies in various "helpful" things which get done to the sound once it leaves a Blu-ray disk. In order to make sure the audio from the movie can be interrupted seamlessly by pleasant sounds like the Windows "warning" noise or the "you've got mail sound", the LPCM isn't passed directly to the audio port-- it's mixed in with whatever other sounds are "needed".

Few enthusiasts trust the player software to leave the sound alone, and even fewer trust Windows to do the same. (And they have reason not to: Microsoft's kmixer (on XP and before) historically munged the sound enough that many sound card designers bypassed it and wrote their own software instead.) If you can send the raw undecoded bitstream, on the other hand, you are exempt from this tampering. The HDMI 1.3 spec is what enables this, and no solution currently exists to do this on the PC. If Intel wins the race to that functionality, it can retain competitive advantage in the audio space.

Beyond this, there is the matter of what Microsoft has dubbed the "Protected Audio-Video Path" or "PAVP".  Basically, the content owners have set requirements on what a player needs to do in order to maintain control of protected material, and Microsoft has translated these requirements into hardware and driver requirements for graphics/audio suppliers (including Intel).  When you get to the bottom of the matter, what it essentially means is that all audio and video need to be encrypted the entire time they're in the PC until they are sent out an analog port or another encrypted interface like HDCP-protected HDMI or DVI.  If this encryption cannot be maintained over the entire path, the player software is required to artifically reduce the quality of the audio before sending it out on the unprotected path.

Right now, there are so few audio solutions which accomodate this that all playback software for Blu-ray downconverts all audio to lower quality, though you might not notice it unless you're a sound fanatic.  But later this year, the player software folks will be modifying their players to pass the full audio over "protected" interfaces.  Intel needs to ensure it's in this space-- right now, doing everything over the (non-encrypted) Intel HD Audio bus, we're in the same boat as everyone else in terms of downconversion.

This article was longer than I expected or even wanted it to be.  The message, if you've bothered to read this far, is: Intel was way ahead in the HDMI Audio game, but the competition has almost caught up.  For a decisive win with HTPC enthusiasts, we need to ensure our HDMI audio solutions are ready for undecoded bitstream transfer of Dolby TruHD and DTS HD MA, and at the same time support whatever PAVP craziness Microsoft has concocted this week.

EDIT: Just a quick note: in my "The Future" section, I should have pointed out that there are a couple of sound card manufacturers who are now working on releasing a "passthrough", where you feed your HDMI video from a video card into your soundcard, which adds the audio and then resends it all out over another HDMI port.  This should work, but it doesn't change the need for Intel to hit this space in their integrated graphics solution.

I'd planned on a big introduction and discussion of what I hope to accomplish here, and I have about half of that written, but I'm not the important bit here, the high- and lowlights of Intel graphics in the Home Theater PC space are.

My plan is to discuss them, sometimes at length, and propose end-user friendly solutions and challenges to our graphics software developers. I'm not one, and don't pretend to know what their problems are; I'm approaching this from an end-user perspective (I own a G965 board) and am bringing back the messages from Consumerville that I'm not sure are being heard. So enough about that.

It's really unfair that my first post is essentially a gripe, but I feel it's important enough (and time sensitive enough, given where our competitors are in this space) right now that I'm skipping all the good things about Intel graphics usage in media and hitting what I consider to be one of the top 3 end-user issues which would prevent a small system builder or an individual from choosing Intel graphics for their Home Theater PC: HDCP repeater mode failures. Without further ado...

HDCP, HDMI, Repeaters, and You

How deep to go on HDCP this early in the game? Suffice it to say that HDCP is a handshake-driven content protection mechanism found in some DVI, most HDMI, and (likely all) DisplayPort interfaces. It enables a source device (a DVD player, Blu-ray player, cable box, or-- in the case we're concerned with-- HTPC) to detect the "sink" device (usually a monitor or A/V receiver) and determine whether said device is "safe".

If the sink device is "unsafe" (has not been given a set of licensed keys), no content will be passed. This is done to increase the difficulty level of someone inventing a device which can make a perfect digital copy of a video/audio stream and thereby providing a path for piracy. If you are a licensed keyholder and do something naughty like create a digital video recorder in violation of the license agreement, you can be fined and ultimately your keys can be removed from the list of valid ones: HDCP source devices will no longer recognize your sink device as valid.

I'm not going to argue about the effectiveness of this technique or even the motivations behind the content owners who demanded this-- my opinions (and I do have some) aren't relevant to the technical issue which needs addressing. It is this:

As of the latest (15.8) Vista drivers, HDCP for a very common usage model is broken on Intel graphics (G965, GM965, G33, G35).

Now there are two kinds of "broken": one exposes Intel to legal ramifications (if our graphics solution sends out protected material without verifying the sink device is licensed, we can be liable) and one just annoys the hell out of customers who merely want to use their systems as advertised.

This is the latter sort, but I think it deserves attention, and my observation of current driver release candidates is making me worry it's either not documented as a sighting or not being addressed. Now, the issue in gory detail:

There are Intel graphics-based motherboards out there right now which issue video over HDMI (we actually are ahead of the competitive pack in that our HDMI solution incorpoates full 7.1 channel audio as well, but that's a topic for another day). The HDMI solutions currently out for Intel graphics consist of a third-party chip which sits on the SDVO bus (muxed into PCIe) and does the conversion from video data to HDMI signalling.

It should be plug and play, and in fact, if you plug an HDMI cable into your Intel-based HDMI motherboard, and then into an HDCP compliant TV set, everything works fine. The HDCP handshake occurs with this solution, detecting the validity of the sink device and telling the software application, "Yes, the video path is protected. Go ahead and send the video." WinDVD and PowerDVD solutions which want HDCP protection for their Blu-ray disks smile happily and run around like a small boy in a field.

This is one usage model; however, it's only half the story. Modern home theaters have lots of different source components (DVD, cable, HTPC, DVR... heck, maybe even an "ancient" VCR), and the usual solution to this problem is to have a switching audio/visual receiver. This consolidates all of the audio and video sources into one box and sends it out to the TV and to the nifty loud speakers in glorious 5.1 sound. This is how things have been done for years, and a significant number of folks operate their systems this way.

HDCP has provisions for this usage model, in fact. When the handshake occurs between the source device and the sink device, a valid sink must inform the source whether it is a "repeater" or not. A repeater is, at its most simple, a device which will be passing the HDCP-protected signal on to another sink device somewhere downstream. Sound familiar? An A/V receiver which is passing HDCP-protected data onward (presumably to another HDCP device like an HDTV) is acting as a repeater, and will report itself as such.

It is this condition which appears to be broken. Plug Intel-enabled HDMI motherboard into a TV: Blu-ray disks will play. Plug Intel-enabled HDMI motherboard into an A/V receiver with an HDTV on the other end: HDCP device invalid error.

It looks from the evidence like repeater mode on Intel graphics enabled HDMI is not working. This is being reported by folks on AVSForum (where I'm a member), and is global across all Intel-based HDMI motherboards, all A/V receivers attempted, and across all legitimate software players (WinDVD, PowerDVD, Arcsoft TMT).

It is not happening with ATI or Nvidia solutions, nor with other HDMI devices (HD DVD or Blu-ray players). It's isolated to Intel graphics.

This is huge for the home theater PC community, a large fraction of whom have multiple source devices and don't just plug directly into a TV. In addition, the competitive advantage we do have in the HDMI audio space is completely destroyed by this problem: if a software application won't send to a receiver because it's a "repeater", the nifty 7.1 channel HDMI audio is useless.

The technical class of nerds in home theater is robust. They have developed a workaround: it's called gray-market software whose name I shall not utter here but whose purpose is to strip the protection mechanism from the aforementioned legitimate software players so they never even request HDCP protection. No protection, no worries about repeater mode.

Problem solved? Does Intel really want to have standard HDMI functionality only work while using gray market hacking software? Of course we don't.

I challenge the Intel graphics software developers and validation teams to correct this in the 15.9 drivers.

Sure, that's easy for me to say: I'm not on that team.

I shouldn't have to be.

I see this as a big miss. I can't imagine how it was missed, with all the validation that goes on both internally and at OEMs, but it looks like a substantial gap. And it's causing end-users to avoid Intel graphics-- which we obviously don't want.

Welcome to the Home Theater PC space: where the enthusiasts will argue for hours over the picture quality of American Idol and will demand 7.1 channel 24bit 192kHz sampled sound on the same.

In this case, they just want their fancy new HDMI A/V receivers to work, as advertised, with Intel graphics. I don't think that part is too much to ask.

That's enough for now. I'll be back another day with more unreasonable demands. At least until they fire me.

AB