XBMC & Broadcom Bring 1080p Decode Upgrade to ill-equipped netbooks, nettops, Apple TVs

We finally have tons of machines that come in these tiny little boxes, sometimes with pretty interfaces, that hook straight up to our TVs. We’ve been asking for this for years and we finally have it. They’re even downright affordable. In order to make them affordable, they use cheap hardware. In particular, slow CPUs. they’re not that bad. Definitely fast enough to browse a bunch of movies or TV shows, but generally too slow to play back high definition video.

Pine Trail, a great little platform, uses very little power, it just can't play 1080p video

NVIDIA built an entire platform out of addressing this deficiency. It’s called ION, and it mates a fast-enough-for-most-things CPU with a GPU capable of decoding 1080p video. Hooray for NVIDIA. Here’s the problem - ION is not retrofittable.

ION, it's a new system, not an upgrade

If you have a non-ION netbook, nettop, AppleTV, Mac Mini, or other impressively tiny device that you want to use to drive high definition video you can’t. And you can’t upgrade them to enable such support.

It’s not like buying a hard drive or more memory. Well, it wasn’t at least.

In one of my last articles on ION I talked about XBMC being one of the best applications for the platform. It delivers a better UI for watching downloaded content than Windows Media Center does, and the Linux version has full hardware acceleration support for ION. Oh, and it’s free.

Last week it got even better. The next major version of XBMC, codenamed Camelot, came out with a whole bunch of new features. I haven’t had a chance to play with it yet but it definitely looks cool.

And today it just got incredible. Thanks to the efforts of Scott Davilla, the XBMC developers and Broadcom there’s now full support for the Broadcom Crystal HD decoder (BCM970012) in all versions of XBMC. The code has been merged into XBMC as of this morning and will be available in the next release of the project.

The mini PCIe BCM970012 from Logic Supply

The Crystal HD chip is currently available on mini PCIe cards, and is expected to make its way to ExpressCard and PCIe x1 cards in the future. This is huge because many netbooks, nettops and existing devices like the AppleTV or Mac Mini have at least one mini PCIe slot. A $69 mini PCIe card (or $25 on eBay) with the Crystal HD chip on it plus the next version of XBMC can enable full 1080p playback on any of these machines that would otherwise not be able to play high def video. Not to mention that you can get some of these devices second hand or refurbished for much less than the cost of a new ION system.

It’s extra sweet because the driver is open source, so we can expect to see it more than just XBMC. The next official release of XBMC is likely some time away, but support has already been added to the SVN release.

The full press release from XBMC is below.

Broadcom Crystal HD, It's Magic.

1080p HD content playback has always been the Holy Grail for any Media Center application but this has traditionally been difficult; playback using software decode alone requires a very hefty CPU and hardware decoding has only been made available recently using the nVidia's VPDAU technology, available only on Linux. Windows has its own platform specific solutions and poor old OSX has no public APIs available at all. There really is nothing around with a common API that enables hardware accelerated 1080p HD content playback that can also be used under all three major platforms (OSX, Linux, and Windows). Well, that situation is about to change.

Through hard work and the joint efforts of several TeamXBMC/Redhat developers and the Broadcom Media PC Group, cross-platform hardware decoding of mpeg2, h.264 and VC1 video content up to 1080p will be coming to XBMC on OSX, Linux, and Windows via the Broadcom Crystal HD Hardware Decoder (BCM970012). The Broadcom Crystal HD is available now in a mini-PCIE card with ExpressCard and 1X PCIE form factors to follow. This means that the AppleTV and all those lovely new netbooks, Eee Boxes and older Intel Mac Minis have exciting new potential.

This solution has a common programming API, so many 3rd party developers and applications will be able to leverage hardware accelerated video content playback across OSX, Linux, and Windows platforms with minimal source code changes. Best of all, this is an open source solution with full source code for driver and library available for OSX and Linux under a GPL/LGPL license. Wow, this indeed is the Holy Grail and a major score for the open source community as this means no more tainted Linux kernels! Support has already been added to XBMC under the svn trunk. Other media projects such as FFmpeg, MythTV and Xine will soon follow as their developers add
support.

The Linux source code for the driver and library can be found at the Broadcom web site. For OSX, the binaries and source code for the driver and library will be hosted at http://crystalhd-for-osx.googlecode.com. Users in the USA can purchase the Crystal HD mini PCIE card from Logic Supply for $69 and of course, there's always ebay for those outside the USA.

Linux Gaming: Are We There Yet?

Introduction by Jarred

A few months back, I wrote an article looking at battery life on a couple of laptops using several different OSes. Windows XP, Vista, and 7 were the main focus, but I decided to test battery life on Linux running Ubuntu as well. Naturally, the Linux community wasn't happy to see their OS place last in the battery life results. One of the readers actually took the time to offer his help in getting a Linux OS configured "properly", and we started work.

Eventually, we abandoned the follow-up article as I had other pressing matters to get to and troubleshooting Linux from half a continent away is difficult (plus we started with the NV52, and ATI support under Linux is still lacking), but I offered Christopher the chance to write a couple pilot Linux articles for our site. He had shown a much better knowledge of Linux and I figured getting someone passionate about the OS was our best bet. (I'll let Christopher tell you what he does for his "real job" if he so desires.)

As a side note, with Anand's call for more writers, this sort of passion for any technology is what we like to see. Show us you know what you're talking about and you care about the technology, and there's a good chance we can use your skills.

With that out of the way, here's Christopher's first Linux article where he provides a concrete look at something few have ever attempted: Windows Gaming on Linux.

---

Over the past few years, there has been a common question on the Linux vs. Windows desktop front: does the Linux desktop have the ability to play various major release games, and if so what is the performance difference between the two? Linux is commonly overlooked as a viable gaming platform in most communities. Our intention today is to shed some light on what does and does not work inside Linux, as well as give solid performance data for those looking for another option in the gaming world. Each OS has areas where it shows superiority over the other, but for the sake of staying true to the purpose of this article we will only be focusing on the game performance/functionality differences.

Unfortunately there are very few game releases that support running inside Linux natively. To combat this issue there are a few Linux projects that will allow Linux users to run Windows applications - note that we did not say "emulate Windows". We have selected three Linux projects in order to complete our initial round of testing. Our open source project selection "Wine" is a free, easily downloadable project that is created to support both Windows games and applications. The second selection, "Cedega", is a closed source implementation of Wine focused on gaming. The final selection is Crossover Games which like Cedega is a closed source implementation of Wine allowing for enhanced usability and gameplay over Wine.

Some are probably asking at this point, what is Wine? The Wine project was started in 1993 to allow Windows applications to be run under Linux. Wine takes the Windows API (Application Programming Interface) and implements it in the Linux user space. Since Wine is running in user space and is not a part of the Linux Kernel, it relies on the wineserver daemon to provide your basic Windows kernel functionality as well as other various tasks of X integration.

As a quick recap, there are two basic goals we want to complete in this article. First we want to compare performance and functionality of games between Linux and Windows. Second, we will look at the performance and functionality differences of Wine/Cedega/Crossover Games.

Revisiting Linux Part 1: A Look at Ubuntu 8.04

Back in the early part of 2008 we decided that we wanted to take a fresh look at Linux on the desktop. To do so we would start with a “switcher” article, giving us the chance to start anew and talk about some important topics while gauging the usability of Linux.

That article was supposed to take a month. As I have been continuously reminded, it has been more than a month. So oft delayed but never forgotten, we have finally finished our look at Ubuntu 8.04, and we hope it has been worth the wait.

There are many places I could have started this article, but the best place to start is why this article exists at all. Obviously some consideration comes from the fact that this is my job, but I have been wanting to seriously try a Linux distribution for quite some time. The fact that so much time has transpired between the last desktop Linux article here at AnandTech and my desire to try Linux makes for an excellent opportunity to give it a shot and do something about our Linux coverage at the same time.

After I threw this idea at Anand, the immediate question was what distribution of Linux should we use. As Linux is just an operating system kernel, and more colloquially it is the combination of the Linux kernel and the GNU toolset (hence the less common name GNU/Linux), this leaves a wide variation of actual distributions out there. Each distribution is its own combination of GNU/Linux, applications, window managers, and more, to get a complete operating system.

Since our target was a desktop distribution with a focus on home usage (rather than being exclusively enterprise focused) the decision was Ubuntu, which has established a strong track record of being easy to install, easy to use, and well supported by its user community. The Linux community has a reputation of being hard to get into for new users, particularly when it comes to getting useful help that doesn’t involve being told to read some esoteric manual (the RTFA mindset), and this is something I wanted to avoid. Ubuntu also has a reputation for not relying on the CLI (Command-Line Interface) as much as some other distributions, which is another element I was shooting for – I may like the CLI, but only when it easily allows me to do a task faster. Otherwise I’d like to avoid the CLI when a GUI is a better way to go about things.

I should add that while we were fishing for suggestions for the first Linux distro to take a look at, we got alot of suggestions for PCLinuxOS. On any given day I don’t get a lot of email, so I’m still not sure what that was about. Regardless, while the decision was to use Ubuntu, it wasn’t made in absence of considering any other distributions. Depending on the reception of this article, we may take a look at other distros.

But with that said, this article serves two purposes for us. It’s first and foremost a review of Ubuntu 8.04. And with 9.04 being out, I’m sure many of you are wondering why we’re reviewing anything other than the latest version of Ubuntu. The short answer is that Ubuntu subscribes to the “publish early, publish often” mantra of development, which means there are many versions, not all of which are necessarily big changes. 8.04 is a Long Term Support release; it’s the most comparable kind of release to a Windows or Mac OS X release. This doesn’t mean 9.04 is not important (which is why we’ll get to it in Part 2), but we wanted to start with a stable release, regardless of age. We’ll talk more about this when we discuss support.

The other purpose for this article is that it’s also our baseline “introduction to Linux” article. Many components of desktop distributions do not vary wildly for the most part, so much of what we talk about here is going to be applicable in future Linux articles. Linux isn’t Ubuntu, but matters of security, some of the applications, and certain performance elements are going to apply to more than just Ubuntu.

AMD and Linux: Reaching for the 64-bit Trophy

Without a viable 64-bit Windows solution available today, enthusiasts and neophytes alike are looking to Linux for new opportunities. Is Linux mature enough to take advantage of the same technology released to the public only months ago? The answers are more complicated than many of us originally thought, particularly considering the competition.

To get a well-rounded breakdown of where Linux is going, and where it trumps (or fails against) Windows, we took the two largest 64-bit Linux distributions, their 32-bit counterparts, and the Windows XP 64-bit public beta for a test drive. The way that we are running the benchmark is slightly unique; we do not recompile or optimize benchmarks per hardware platform. Our goal is to see which out-of-the-box operating system performs the best with as much support as possible. Thus, we use RPMs and binaries packaged with or compiled for the specific operating system tested.

Performance Test Configuration
Processor(s):	Athlon 64 3500+ Socket 939 (2.2GHz, 512KB Cache)
RAM:	2 x 512MB Mushkin PC3500 Level II
Memory Timings:	Default
Hard Drives	Seagate 120GB 7200RPM IDE (8Mb buffer)
Video AGP & IDE Bus Master Drivers:	Linux NVIDIA Core Logic: 1.0-275 Linux NVIDIA Graphics: 1.0-5332 Windows 64 bit Graphics: 57.30 Windows 64 bit Core Logic: 4.34a
Video Card(s):	NVIDIA GeForceFX 5600SE 128MB
Operating System(s):	SuSE 9.1 Professional (32/64 bit) Fedora Core 2 (32/64 bit) Windows XP SP1 (32/64* bit)
Motherboards:	NVIDIA NForce3 250 Reference Board

*Windows XP SP1 64-bit is the February 2004 open beta release.

We attempted to keep our test configuration as close to CPU/Motherboard/Memory Windows test configuration as possible. The only major change that we adopted for this analysis include the change in processor, IDE rather than SATA hard drive, and the NVIDIA GeForceFX video card. We opted for an NVIDIA card over an ATI card for these benchmarks primarily because of 64-bit Linux driver support. We have a Linux video card roundup planned for the future; so, in that article, we can take a better look at where the particular differences lie in video processing.

Building a Linux PVR Part I - MythTV Setup and Install

Introduction

Once in a while, we get so excited about writing an article that we completely lose focus and end up with a 10,000 word epic instead of a concise little review. This two-part Linux TiVo article ended up being one of those articles. Of course, we aren't really building a Linux TiVo, but rather something as close as we can come, with some rudimentary hardware and free software - such as Linux and MythTV.

Considering the cost of a TiVo, service runs anywhere from $100 to $600 per year depending on what DVR and subscription you buy. Building a moderate MythTV machine for around $500 actually saves us money in the long run. Building our own device also allows us to upgrade hardware easily and reconfigure the software at our will.

Ultimately, we would like our machine comparable to a TiVo device; but in actuality, we really would like it to perform as well or better than a machine based on the same hardware running the newest Windows Media Center (Anand wrote a small MCE introduction 18 months ago). Recently, we obtained a new whitebox Media Center device with similar hardware found in this Part I of our Linux TiVo experiment. Our goal for Part I of the article is to get Linux, MythTV and all the trimmings working successfully so that we can square both machines off against each other; and then compare encoding, image quality and functionality. We are publishing Part I: The Installation today, but expect Part II: The Comparison in just a few days.

If all goes well, we will probably follow up with a Part III some weeks later, dissecting Freevo, GeexBox, etc.

Doom3 Linux and Windows Battlegrounds

Introduction

Doom3 was a turning point for a lot of us as it marked an important milestone in next generation game engines. We have been keeping a very close eye on id's Linux adventure, and at the core of id's Linux development is Timothee Besset, the Linux port maintainer.

"I'm getting surprisingly good performance compared to the Windows version."

Timothee Besset, Linuxgames.com [1]

This sounds like the premise of a wonderful opportunity to put Doom3 through its paces. We crafted this entire analysis around Timothee's expectations.

Our goals for this analysis are twofold. We want to take the newest working video cards that we can find and test their performance on Linux using Doom3. This is slightly a continuation of last week's GPU roundup as the Doom3 engine will ultimately become the next cornerstone for Linux first-person shooter games. This includes exhaustive image quality (IQ) testing. Secondly, we wish to run comparative analysis on how Doom3 performs and looks on Linux versus Windows.

Building a Better (Linux) GPU Benchmark

For those who follow our Linux reviews, we have made a lot of headway in the last two months. Our benchmarking has improved, our graph engine is top notch and we are working closely with all the major manufacturers to bring a definitive resource for Linux hardware to our readers. Today, we want to introduce everyone to our GPU Linux benchmarks and how we will run them in the future. This isn't a comparative analysis yet, but we won't keep you waiting long for that.The adherent flaw with any benchmark is that you, the reader, only receives a sampling of data - engineers and statisticians alike call this "data compression". When we sample data from a timedemo and format it into an average frames per second, we lose all sort of valuable data, such as what the lowest frames per second was, what the highest was, when the largest dip in FPS had occured, what the image looked like, and the list goes on. There have been a few attempts to convey more than just an average FPS in video benchmarks, most notably with FRAPS. FRAPS does not entirely address the issue of reproducibility and FRAPS runs on Windows only. Fortunately, we have been graced with some very talented programmers who worked with us to build a benchmarking utility similar to FRAPS (on Linux) that we may eventually port over to Windows as well. Consider this to be our experiment in advancing our benchmarking methods while using Linux as our guinea pig. Eventually, we anticipate releasing the benchmark complete with source to the public. Here is how our utility works, as explained by the lead developer, Wiktor Kopec.
"The program computes frames per second for an application that uses OpenGL or SDL. It also takes screenshots periodically, and creates an overlay to display the current FPS/time."This is accomplished by defining a custom SwapBuffers function. For executables that are linked to GL at compile time, the LD_PRELOAD environment variable is used to invoke the custom SwapBuffers function. For executables that use run-time linking - which seems to be the case for most games - a copy of the binary is made, and all references to libGL and the original glXSwapBuffers function are replaced by references to our library and the custom SwapBuffers function. A similar procedure is done for SDL. We can then do all calculations on the frame buffer or simply dump the frame at will."You can read more about SDL and OpenGL. SDL is a "newer" library bundled with most recent Linux games (Medal of Honor: AA, Unreal Tournament 2004). In many ways, SDL behaves very similarly to DirectX for Linux, but utilizes OpenGL for 3D acceleration.

Building a Better (Linux) GPU Benchmark

For those who follow our Linux reviews, we have made a lot of headway in the last two months. Our benchmarking has improved, our graph engine is top notch and we are working closely with all the major manufacturers to bring a definitive resource for Linux hardware to our readers. Today, we want to introduce everyone to our GPU Linux benchmarks and how we will run them in the future. This isn't a comparative analysis yet, but we won't keep you waiting long for that.The adherent flaw with any benchmark is that you, the reader, only receives a sampling of data - engineers and statisticians alike call this "data compression". When we sample data from a timedemo and format it into an average frames per second, we lose all sort of valuable data, such as what the lowest frames per second was, what the highest was, when the largest dip in FPS had occured, what the image looked like, and the list goes on. There have been a few attempts to convey more than just an average FPS in video benchmarks, most notably with FRAPS. FRAPS does not entirely address the issue of reproducibility and FRAPS runs on Windows only. Fortunately, we have been graced with some very talented programmers who worked with us to build a benchmarking utility similar to FRAPS (on Linux) that we may eventually port over to Windows as well. Consider this to be our experiment in advancing our benchmarking methods while using Linux as our guinea pig. Eventually, we anticipate releasing the benchmark complete with source to the public. Here is how our utility works, as explained by the lead developer, Wiktor Kopec.
"The program computes frames per second for an application that uses OpenGL or SDL. It also takes screenshots periodically, and creates an overlay to display the current FPS/time."This is accomplished by defining a custom SwapBuffers function. For executables that are linked to GL at compile time, the LD_PRELOAD environment variable is used to invoke the custom SwapBuffers function. For executables that use run-time linking - which seems to be the case for most games - a copy of the binary is made, and all references to libGL and the original glXSwapBuffers function are replaced by references to our library and the custom SwapBuffers function. A similar procedure is done for SDL. We can then do all calculations on the frame buffer or simply dump the frame at will."You can read more about SDL and OpenGL. SDL is a "newer" library bundled with most recent Linux games (Medal of Honor: AA, Unreal Tournament 2004). In many ways, SDL behaves very similarly to DirectX for Linux, but utilizes OpenGL for 3D acceleration.

Dual Core Linux Performance: Two Penguins are Better than One

With all of the attention on dual core processors lately, it has been real easy to overlook the one application that might benefit more from multiple cores than any other; Linux. OK, so technically Linux isn't an application, but the kernel has supported SMP for nine years almost to the date. The road to SMP has not been an easy one for Linux, but in the last nine years, and particularly since 1999, Linux has received quite the attention as a 2-8 processor core operating system. If you need a reference, just look at how many Linux machines hold SPEC benchmark records in web serving and number crunching.
But does any of this translate to great desktop performance for dual core processors? We are going to look at that question today while also determining whether Intel or AMD is the better suited contender for the Linux desktop. We have some slightly non-traditional (but very replicable) tests we plan on running today that should demonstrate the strengths of each processor family as well as the difference between some similar Windows tests that we have performed in the past on similar configurations. Ultimately, we would love to see a Linux configuration perform the same task as a Windows machine but faster.
Just to recap, the scope of today's exploration will be to determine which configuration offers the best performance per buck on Linux, and whether or not any of these configurations out perform similar Windows machines running similar benchmarks. It becomes real easy to lose the scope of the analysis otherwise. We obtained some reasonably priced dual core Intel and AMD processors for our benchmarks today, and we will also throw in some benchmarks of newer single core chips to give some point of reference.