Home Media PC

Just about a year ago, I converted my music library to digital form—and I love it. The CDs are all ripped to lossless FLAC format. I've got a small computer (running Ubuntu Linux) in the living room connected to the A/V receiver by S/PDIF optical connection. The fidelity from this hardware isn't quite as good as the original CD player, but it's close.

I've spent a lot of time—maybe too much time—trying to get the music organized. A lot of the work was spent trying to get the metadata right. I'm going to write a couple of blog articles about my adventures. Today, I'm going to talk about gathering the metadata—stuff you probably know if you've been through this already.

I recently thought it was time to get a disk-based MP3 player. I already had an inexpensive flash memory player, which was great for carrying a dozen albums on an afternoon road trip, but I wanted something big enough to carry my music collection into work.

My two key product requirements were:

• Open platform.
• Good sound.

Requirement number one knocked the Apple iPod product line right out.

I built a home media PC last October using an Asus Pundit-R "booksize" computer and Ubuntu Linux. You can read about the saga in my home media PC category.

Where we last left our story, there were two remaining items on my "less than ideal" list: the system was noiser than I'd like and hibernation wasn't working.

I have some better understanding—no progress—to report on the noise issue. The system is still louder than I'd like. It's not as loud as, say, a Sony Playstation 2, but it's still annoying to me. After all, people typically don't try to play André Segovia classical guitar music on a PS2.

I may be stuck and I suspect the CPU may be the culprit. I built the system with an Intel Celeron D 335 (2.8GHz) Prescott processor. It seems the Prescott architecture is notorious for heat and power issues. I wish I could swap it out for a Celeron M (Dothan) processor. The "M" stands for mobile (as in built for laptops), and they sound like great processors: zippy on the MIPs and stingy on the watts. (My Dell Inspiron 600m laptop uses a Pentium M and it kicks butt relative to its clock speed.) Unfortunately, it appears even though the Celeron D and Celeron M processors are both "Socket 478" packages, they are not plug compatible. (I've seen the notation "Socket 478M" to distinguish the latter.)

It's times like this I wish I had a good tweaking motherboard—not to overclock the processor but rather to underclock it and slow down the power burn.

Now, on to the good news: I got hibernation to work. Actually, the system would hibernate correctly—the problem was with resume. The system would resume alright into text mode, but would hang when it tried to enable graphics. My dilemma was that the ATI proprietary fglrx driver doesn't support hibernation, but the open source ati driver doesn't support the TV output.

The solution I found was to use the dumb vesa frame buffer driver. That gives me a display without video acceleration, but I really don't need it for typical use. The only thing remotely graphically involved I do is visualizations for the music player, and that continues to work fine on the vesa framebuffer.

Here are the steps I performed to make this work:

• Make a backup copy of the /etc/X11/xorg.conf file.
• Run sudo dpkg-reconfigure xserver-xorg
• When asked to "autodetect video hardware" select "no".
• Select "vesa" driver.
• Pretty much take the defaults. The only place I didn't was when asked whether to use the "kernel framebuffer device interface". The default was "no" but I selected "yes".
• When asked for "video modes you would like the X server to use" I selected 800x600 and 640x480 (i.e. turned off 1024x768).
• I selected the "medium" option for "selecting your monitor characteristics".
• Then, I selected an "800x600 @ 60Hz" monitor.

With the configuration complete I restarted X and verified that the TV-out was still working correctly. Then I ran sudo /etc/acpi/hibernate.sh and watched the machine hibernate. When I rebooted the machine it found the suspend image, loaded it up, and brought me right back to where I was.

The results are great. Now, when I want to listen to music, it takes just 35 seconds for the computer to return from hibernation. The cold boot, by comparison, takes about 1:40—that's about 60 seconds to boot Linux and 40 seconds to start the KDE desktop. This is a significant improvement.

One of the issues with my media PC (Ubuntu 5.10 Linux on an ASUS Pundit-R) is that it doesn't hibernate correctly. This means I need to do a full boot to listen to a CD, and a full system shutdown when I'm done.

I've made some recent progress, but I'm not there yet. I've found two things.

First, it appears I've been running into APIC problems. If I disable it, either in BIOS or by specifying noapic on the Linux boot command line, then I can hibernate in text mode. That is, if I take a running system, switch to a text console, and then run /etc/acip-support/hibernate.sh then it hibernates correctly. Well, that part always worked. The exciting part is that when I power on, the system resumes correctly to a shell prompt. Before, with the APIC enabled, it would hang.

The problem I have now is that when I switch the console back to the graphics mode, I get a partial redraw of the screen and it hangs. According to a thread over at the Ubuntuforums site, this is a known problem with the proprietary ATI video driver (fglrx). The open source driver (ati) is supposed to be ok, but that driver doesn't support TV output.

There is an updated fglrx driver available, and I have some hope this may fix the problem. Unfortunately, it looks like the update is a pain in the butt to do. When I can, I'll give that a try and report back.

I've spent the better part of the afternoon performing a BIOS update of my ASUS Pundit-R system. I finally found a procedure that works—and about ten that didn't. I'll describe how I did it, in the hope that it prevents somebody else from following my same path of agony. This procedure may be applicable to other systems, particularly those that use AMI BIOS and the AFUDOS BIOS flash update utility.

It's hard to believe that it's been over a month since I built my Linux based home media PC. My entire CD collection (about 250 discs) has been digitized, and I'm ready to move the physical relics all into storage.

The system is working fine. There are, however, a number of remaining issues that keep me from completely endorsing the ASUS Pundit-R for home media applications. Garry Parker wrote about putting Myth TV on the Pundit-R, and he identified a number of weaknesses. He says:

After living with the Pundit for a while, the main problem with it is that it's too loud. It's quieter than most desktop PCs, but is still louder than I'd like for a living room. The alternative would be a passively cooled system such as an EPIA, but the extra power is probably worth it.

He also notes, "The SPDIF digital output is on the front panel. This is crap and a real design flaw." I agree. I encoded my CDs in a lossless format (FLAC) to preserve full fidelity. Yet, I'm playing them back through the computer's low-to-mid-fi analog system. I really want to play the bits digitally to preserve the fidelity, but if I do I need to leave the front panel open with a cable hanging out. That's crap.

The sound quality issue is a big deal. I ran an A-B test, to compare the sound of a full-fidelity FLAC file played on the computer (analog stereo connection) to the original CD played on a DVD player with S/PDIF (digital optical) audio connection to the amp. The difference is significant. The presence is completely sucked out of the version played on the computer.

My other complaint is that the system does not return from hibernation correctly. This may be a Ubuntu 5.10 issue, but regardless of the cause, it is an annoying one. The system would be a lot nicer to use if I could hibernate when not needed, and quickly resume when I want to play or access music. This means I either need to keep the computer running or go through a long boot-up when I want to use it.

Originally, I planned to do both audio and video media with this system. I haven't done any work on the video, and, frankly, I'm not working up much motivation to do so. We don't have cable and our TV reception sucks. About the only thing I watch is the Simpson's repeats on Fox. Counting time and materials, it would be cheaper to just buy the box set DVDs than it would be build video capability.

So, I'm mostly satisfied with the audio capability, and I don't anticipate working on video anytime soon. When I do, maybe I'll be ready to upgrade to a box that addresses some of the problems I found.

I am using a Dell wireless keyboard for the home media PC that I am building. After so many difficulties setting up the system, it's nice to report a small success: I got the multimedia keys on the keyboard programmed.

RF wireless is great: I can control the computer from the couch. The wireless base receiver plugs into USB and Linux boots fine. I did have to relocate the receiver outside the equipment cabinet. All those metal boxes must have blocked the radio signal from getting through.

Video connections sure are confusing. I have a degree in electrical engineering from an Ivy League institution, and I'm befuddled by it all. I feel sorry for you mere mortals out there.

I'm building a media PC from scratch, and I'm trying to get a good video display. Mind you, at this point, I'm not trying to play video media. I'm just trying to wring the fuzzies out of the display when I run the music player or web browser.

The computer has VGA, S-Video, and DVI video outputs. The television has composite, S-Video, component video, and HDMI inputs. You'd think that with all those choices, there would be some way to insert tab A into slot B and make it all work.

The first and obvious choice is S-Video–both units have that. In fact, as I reported in that prior article, S-Video works. Unfortunately, it doesn't work so good. You may be surprised to learn that S-Video has the same crappy resolution as the bottom-of-the-line composite video connnector. Both do 480 interlaced scan lines, The difference is that S-Video separates out the signals so it's a crisper 480i. That means with S-Video, I'm trying to display 800x600 on 480 interlaced scan lines–no wonder it looks like crap.

I wanted to do better, but S-Video is the only connection the two had in common. The "high def quality" component video TV inputs would be ideal, but the computer doesn't have matching outputs.

After some web searches I found an adapter jig that would connect up to the DVI connector of an ATI video card and produce component video. My on-board video is ATI, so I thought this would be a shoo-in. All I needed was this one cheap adapter and it was component video all the way.

Well, not quite so fast Poindexter. When I got the adapter it wouldn't fit. That's when I learned that there isn't just one kind of DVI connector. There is DVI with digital video signals (DVI-D), analog video signals (DVI-A), and a combination of the two (DVI-I). Moreover, there are single-link and double-link DVI-D connectors (double has more pins). This adapter jig was made for a DVI-I connector, and it used the analog outputs to produce component video. My computer has a DVI-D connector with no place for the analog pins to fit into. That's why the connector wouldn't fit.

So, it was back to the drawing board. I found devices that convert DVI-D to component video, but at over a hundred bucks that didn't make sense. I thought about getting a DVI-D to HDMI cable, but they aren't cheap. Moreover, the A/V receiver I have my eye on has component video inputs but not HDMI. I really want to get component video.

I concluded there is no reasonable way to go from digital DVI to analog component video. But what if I could do analog all the way? That got me thinking: computer VGA is an analog video signal. Is there some way I could get component video from a VGA output? Unfortunately, not easily. The signals aren't compatible. VGA uses RGB (red, green, blue level) signals, while component video is YPbPr. It appears that at least some ATI adapters can be kludged to produce component video signals on the VGA connector. Even if my hardware can support that, I'm not sure if the Linux fglrx video driver can. I haven't ruled it out, but it's a longshot at best.

I'm not sure if I'm getting any closer to a solution, but I'm getting a heck of an education on video interconnections.

FedEx delivered the parts for my new media PC today. It took a few hours time (and an unplanned run to Fry's Electronics) to put it together, but now I'm ripping and playing CDs.

Here are the parts I'm using:

• ASUS Pundit-R "booksize" barebone computer
• Intel Celeron D 335 Prescott CPU, 533MHz FSB, 2.8GHz operating freq
• Hitachi Deskstar T7K250 160GB SATA hard drive
• NEC ND-3540A DVD Burner
• two Kingston 256MB DDR400 CL3 memory modules
• IOGEAR GWU523 USB 802.11G WiFi adapter

Next week, I'm building a Linux-based media PC. I've been doing some research and planning. The first goal is to setup a digital music library. I started my research at the beginning, with CD ripping. My initial performance results were so bad, it called the whole project into question—or, at least, the decision to use Linux.

Here is a message I posted to the Austin Linux User's Group mailing list.

I'm getting ready to setup a media system, and I'm distressed at the thoroughly horrible CD ripping performance I'm seeing.

My test system is a Dell Dimension P4 2.8GHz with 512MB memory and Phillips DVD8631 (40x speed).

When ripping under Linux (Ubuntu 5.04), it takes about 25 minutes to RIP a CD. I've tried both Sound Juicer (reports about 4x performance ripping to FLAC) and cdda2wav (rip to WAV).

When I reboot the system to Windows, Apple iTunes rips the disc in about 4 minutes (reports about 30x performance).

It turns out that although ripping performance may be slow in the default Linux configuration, there are adjustments you can make such that Linux can actually rip faster than Windows.

There are two significant issues that lower Linux ripping speed. First, for stability reasons, most Linux distributions do not enable DMA for the CD drive. If your system can handle it (I think most modern systems can), then you should enable it with the hdparm command. To do so, run (as root):

# hdparm -d1 /dev/cdrom

On Debian systems, you can make this setting permanent by editing the /etc/hdparm.conf file.

The second issue is that most Linux CD ripping tools enable error checking (sometimes called "paranoia") by default, while most Windows tools do not. If you disable error checking, you will see a significant improvement in ripping performance. It's not clear that this is an advisable adjustment, but it explains part of the significant performance difference.

I ran some tests on the aforementioned Dell system to measure the effect of these various settings. I used the grip CD ripping tool and ripped to raw WAV format. The trials were all timed by the wall clock, so take the results as plus/minus a few seconds.

By comparison, when I rebooted this system into Windows XP and ripped with Windows Media Player to Windows Lossless Format, it took 2:23. (This isn't quite apples-to-apples since there was an additional encoding step under Windows, but that should have only added a few seconds at most.) This was an unexpected surprise: Linux actually outperformed Windows. I was shocked, given how poor the initial results were.

Now that I'm over this hump, the research continues. I'd like to investigate whether "error checking" is a valuable protection, or unnecessary overhead. Also, I need to determine which ripping and playing tools I want to use. A database backend would be nice. I'm pretty sure I want to rip into the lossless FLAC format. I need to verify that's going to be feasible for our CD collection.