Today I tried out the Solaris version of VirtualBox on my OpenSolaris 2008.05 laptop.

My laptop is a Sony VAIO, a Centrino Pro processor based system. The first decision you need to make is whether you need to download the 32 bit or the 64 bit version. They recommend using the command isainfo -k in a terminal window to see which mode Solaris is running in. Solaris has a single distribution for both 32 bit and 64-bit capable CPUs, and at runtime, it picks the best mode. Since my system supports EM64T (extended memory 64 technology), OpenSolaris is running in 64 bit mode, so I downloaded that one.

After the download and untar, the instructions for installing the package are quite straightforward.

One small criticism is that you need to launch VirtualBox from the command line; it should install something in the Gnome desktop menus.

Once I launched VirtualBox, I was able to define a new Windows guest, give it around 1GB of memory (I am running with 2GB on the laptop), point the CD-ROM at the .iso file of Windows XP, and boot away. The install went flawlessly, and I was able to bring up Windows XP just fine. Also installing the Windows Guest extensions worked fine as well.

Networking and audio came through from Windows into Solaris, and since audio works in OpenSolaris, I was able to hear the Windows sounds just fine. Note that if you turn on seamless mode, you might not want to reboot your guest, as the display will be... um... interesting. Though this seems to happen with Windows as the host as well.

Of the two configurations I have tried (running OpenSolaris as a guest under Windows or running Windows as a guest under OpenSolaris), I actually think I prefer this one.

• I could probably live my whole life in OpenSolaris and just use windows for those few times I just can't get away from it (like running my company expense reporting tool).
• Compiz, the 3D graphical desktop under Gnome is a lot cooler than the effects on Windows.
• I still need to figure out how to get my Windows guest to drill through the company firewall to set up a VPN connection, but I might have a website which explains how to do this.
• My 3945 wireless connection on OpenSolaris doesn't seem to want to stay as stable as the Windows wireless networking. Perhaps need an upgrade to 4965!

I've been monitoring how many developers are watching all of the segments of the video series we've posted on the Take Five site.   It is natural that not everyone will make it to the end, but I'm wondering if there is anything we could do better.

First, I'd like to know if any of these are the causes:
  A) Didn't know series were there
  B) Watched the video from a different page w/out the series navigation
  C) Didn't have time to watch them all
  D) The video, well, just wasn't that interesting
  E) My boss walked by, and I had to quickly switch screens from videos
  F)  Other:  ______________ 

Take a look at two of the series we've posted from the Game Developers Conference:  Optimizing DirectX for Mulicore, or the SkullTrail series with GRIN Software* and UbiSoft*.  Or the very long Confronting ManyCore series.   Once a video is playing in the player at the top of the site, there is a link that says "see Next in series" and/or "see Previous in series" to easily (at least I thought) move from one to the next. 

While you in the player, you can rate the videos, get the embed code and direct links, leave comments, and/or link back to the blogs.

To see more series, they are in "series boxes" on the tabs below the Take Five player.  If you mouse over the numer, you will get a video description. Be sure to click on the blue arrow to see the Virtualization and Community, and coming soon, Open Source tabs. 

I'd love to hear your comments, and answers to the mulitple choice above.  I'm hoping I don't get too many D's.

Happy Friday!

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 cannot envision a more exciting time to be working in the technology industry, and especially, at Intel. Tick-tock, multi-core, low power, atom, larrabee, wimax, mids, 45nm are just a few of the potentially game changing strategies and technologies that Intel is driving today. However, none of these breakthroughs will make a big difference in the marketplace unless ISVs can effectively incorporate them into products that deliver real value and excitement to customers. This is the ‘simple’ premise behind ISPP: Make it easy for ISVs to align their products with the Intel roadmap and enjoy increased business success as a result.

In my past life as an engineer, I got a real kick in the pants from creating new SW and hearing feedback from customers about how cool our app was…or sometimes, wasn't! These days my ‘kick’ comes from driving our talented engineering, ISN developer community, and marketing teams to deliver enabling programs that help you and your company to capitalize on Intel's technology leadership. I’m looking forward to sharing my thoughts and ideas about SW enabling in future posts, but am even more eager to hear your feedback about how we can make ISPP work better. Simple enough?

 I am working with some of the brightest folks here at Intel, our subject matter experts and architects, such as Clay Breshears, Michael Wrinn, Bob Chesebrough and Tim Mattson (amongst others).  I will also be working closely with the indomitable Wolfgang Rosenberg, manager of the Intel Academic Community. 

My job is to reach out to educators and researchers around the world, to connect them with Intel experts and to help foster development of a curriculum to educate the next generation of programmers and engineers on the newest compute platforms.

Hopefully, this blog will go a long way to opening up channels of communication 

We have a number of events and initiatives planned for this year. 

We have already started our monthly Academic Community Curriculum Webinar Series.  During these webinars, we discuss the newest curriculum topics.  It is a great way to speak directly with our course architects.  I moderate the series and I very much look forward to speaking with you there soon.

The next in the series is on May 15 on multi-core design patterns.  Please Register below.

 Register or view past event here.

------------------------------------------

We are creating quite a few short videos supporting our academic efforts.

 I'm in the process now of filming a series on threading topics with an emphasis on game development and visual computing.  So far only the first title on Optimizing for DirectX is posted, but the rest will be available soon.

Is this type of content useful?  Are there better ways to scale out our knowledge and build conversation?  I'd like to hear that from you.

 I've asked around internally as to how folks like to consume information.  As you might imagine, there were a wide-range of responses.  Tim Mattson just rolled his eyes when I started to talk about videos and webinars.  While he is a great presenter, his own preference is to just download the PowerPoint or code and have done with it.

Others, myself included, prefer a richer content set.  For me, nothing beats the immediacy of a live event.  That is one reason we have our monthly webinars.  I am also quite interested in convening smaller conversations, perhaps using something like Communicator or Live Meeting, to discuss specific topics or curriculum ideas.  Let me know by responding to this blog.

 ---------------------------------------------

Finally, I've become very interested in different forms of new media.  I'm often available on Twitter -find me as @psteinb.

I am the owner of the Intel Software Second Life Island. 

IM me on Second Life as Peretz Stine.

Check out our launch video.

Over the last year, we ran an event series on our Second Life island dedicated to engaging engineers and professionals around the world in conversation on this unique environment.  That program, sadly, is ended, but you can still view much of it here:

Are you interested in meeting on Second Life or other virtual worlds?  It can be arranged.

 Well that's enough for now -you have you orders -tell me how best to foster dialogue.  I'll be working as hard as I can, but you are the whole point.  Let's start the conversation.

Some initial impressions:

1. The OS comes as a LiveCD. This means you can pop the CD into your drive,
reboot your computer and (assuming that the CD is in the boot path) you
can boot up OpenSolaris and give it a try. You don't need to install it on
your computer's hard drive to check it out. You can see what works and if
anything doesn't, and then if you like it, install the OS. This worked like
a champ!

2. The visual presentation of the OS is just beautiful. I was kind of
uninspired by the new bubbles logo for OpenSolaris. But when I installed
the OS, I was startled by how beautiful the look is.

3. So much stuff just works out of the box on my Centrino Pro. I was able to
wireless LAN right away of course on the last-generation 3945 chip. But
audio worked for me right away! This is honestly the first time I have
had sound worked for me out of the box without any fussing.

Now time for full disclosure: Not everything is perfect on all systems. I
also spun up the LiveCD on my Lenovo T61 Centrino Pro, and the audio wasn't
working, so your mileage may vary. Try it out and send feedback!

4. compiz is integrated with the window manager now. This means if you
have a decent 3D graphics chip, you can get these awesome 3D window effects
by selecting System->Preferences->Appearance from the top bar and then select
then select the Visual Effects tab. (I wouldn't necessarily try this in
a virtual guest, since I would imagine some odd things might happen). If
you are not familiar with compiz, you really should try it. You will truly
impress your friends who use Vista or Mac OS as to how cool and fun your
OpenSolaris desktop can be.

I showed off my laptop to my friend Max who couldn't believe everything
had worked so well out of the box. "Didn't you install some packages?" No, the
great thing is, all of these things "just work" out of the box on this PC.

I'm still playing with the distribution - I have yet to dive into package
installs for example. But I'm very excited that things worked so well
already.

Edited to Add: Thanks for all of the commenters who kindly pointed out that I had put "2009.05" instead of "2008.05" in the title of the post originally.  Guess I was just too excited!

There's got to be a catch

There are 5 CC-states and, depending upon how you count, 6 PC-states in the Penryn line of Intel processors. And, in Microsoft XP, there are 4 OS C-states. So are there 5 C-states, 6 C-states, 4 C-states, or 15 C-states? Choose the number that you are least uncomfortable with. Personally, I first imagine a 3 set Venn diagram with overlapping elements and added transition annotations. Then I get confused and give up. 

Given what we've talked about above, it seems as if we should always drop a core into the lowest permissible CC-state, right? 

There are a few reasons for not doing this. First off, the OS's Power Management (PM) policy, and not the hardware, determines when a core enters a CC-state. From our standpoint as a hardware manufacturer, we have little to do with this. I'll talk about why this is important later. Secondly, there is always a cost for dropping into a lower C-state. That cost is the amount of time required for the core to transition from an idle state, e.g. CC5, to C0. As you start using deeper CC-states, latency becomes significant. For example, the latency to go from CC3 to CC0 is around 20 us, literally ages when we're talking about 3 GHz processors. 

This latency penalty is even worse once you realize that the phrase, "in a given C-state," is misleading. As I've mentioned above, it's easy to think of a core as descending as a waterfall from C0 into C1 into C2 into C3. (See Figure A.) If this were the case, you'd suffer only one 20 usec penalty. No, it's oscillating between C0 and C3 hundreds, if not thousands, of times a second until the OS's PM code decides that the percentage residency merits ascending / descending to the next C-state (e.g. CC3 to CC2). In Windows, the C-state that a core transitions to is based on the % idle over a certain interval. This means that each transition exacts that 20 usec penalty, and there are hundreds of transitions. Doing the math, experiencing a 20 usec delay 100 times a second is a whopping 2 msec of added latency per second. (See Figure B.) 

Even if it is possible to drop a core into a deeper CC-state, the OS has to ask itself various questions, such as what is the likelihood that processes are going to be doing more work very soon, so that dropping into a deeper CC-state might actually cost an unacceptable penalty? Similarly, the processor has to ask whether dropping a core into a lower CC-state is going to cause incorrect operation, say whether the delay in the processing of an interrupt will cause an event to be lost.

Figure A. The waterfall misconception.

Figure B. What actually happens "in a given C-state".

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.