This article describes how to build your own silent, fast, eco-friendly Linux-based PC for use in a digital music listening system. The PC is based on a high-end Via mini-ITX board, passively cooled case with heatpipe technology, Debian Linux, and a little creative embedded elbow grease.

(Click for larger view of final installation)

Spread the word: digg this story

This system is the fourth dedicated Linux-based music server that I've built over the past eight years. For the first time, though, I tried to do the job right, rather than just making do with spare parts. After all, digital music is no longer an interesting experiment, but the primary focus of my listening setup, despite all of that vinyl gathering dust in the basement.

Sonos Digital Music System (Click for details)

Vendors of Linux-based music equipment (Sonos comes to mind) often poke fun at amateurs like me who still roll their own — arguably for good reason. Commercial systems like the Sonos Digital Music System (pictured at right) have slick features like synchronized multi-room playback that are light years beyond my crude hacking capabilities.

Yet, a real Linux computer is a toolbox that can do anything the user is capable of doing with it. For about the cost of an entry-level Sonos setup, the system described here can also serve as a LAMP server and development host, a digital video recorder with high-definition component video capabilities, or as a silent livingroom Web and email kiosk, to name a few possibilities. So, there are tradeoffs on both sides of the build/buy equation.

Defining the system

Let's start out with a diagram of the various components that will interoperate with our silent mini-ITX system (outlined in red). It might look a little complicated at first, but there's a lot of flexibility in this architecture.

We'll build the component outlined in red
(Click to enlarge)
This architecture could be described as a “separates” approach to digital stereo components, in which each component does one thing — hopefully really well:

• Remote storage banishes noisy disks from the listening area, while RAID (redundant) ensures you won't lose your collection.
• The silent, solid state mini-ITX PC we'll build serves up a simple browser-based user interface that works on its own monitor, if you choose to give it one, or from anywhere on the network. It also ably handles digital-to-audio conversion via a high-definition audio codec.
• A handheld Web tablet with a browser offers a convenient remote control. And, it can also serve as an output device itself, playing files streamed from the NAS server via UPnP, or music streamed from services such as Rhapsody.

Each of the three systems above runs Linux. The NAS is a Linux-based Infrant NV+, which costs about $1,000 with four 250GB drives. That's quite a bit, but you'd eventually have to buy something similar with a Sonos setup, unless you wanted to run your PC just to listen to music. According to my Kill-a-Watt meter, the Infrant burns 55 Watts in use, but can be configured to spin down to 25 Watts after 5 minutes of inactivity. A power button makes shutting down and starting the device simple (but mind your NFS mounts first).

The web tablet is Nokia's Linux-based N800, which runs about $350. Alternatively, Nokia's older Linux-based 770 tablet can do everything the N800 does, except Rhapsody, and is available for half as much. Actually, I think there are more mpd clients available for the older 770, including glurp, a GTK+ based client for mpd. Compared to browser-based mpd clients, stateful clients like glurp generally offer more responsive, granular volume controls, but are not as easy to use.

The rest of the parts should already be in place on most anyone's home network.

Now that we understand the basic architecture, let's get started putting the mini-ITX system together!

Assembling the mini-ITX system

I chose the EPIA EX-15000G, the first Via mini-ITX board with onboard digital video and a DVI connector. It also sports component video out, two RCA stereo audio outs, and lots of other multimedia-oriented I/O. Once the music server's up and running, there'll be lots of digital video capabilities to explore!

Epia EX back-panel I/O
(Click for labels)
Processor-wise, the EX-15000G features Via's top-of-range C7 processor clocked at 1.5GHz, along with the CX700M(2) integrated north/southbridge chip. Interestingly, Via also offers a nano-ITX version of the EX-15000 called the NX-1000 and a pico-ITX version called the PX-1000… for system builders with more advanced skills than mine.

For a case, I chose Serener's very simple, nice-looking Serener GS-L05 model, a solid black anodized block measuring 7.5 x 7.25 x 3 inches. It was the only case I could find with an available heatpipe for the EX-15000G board. By now, some of Serener's larger, fancier “media PC” cases may also support the board, but I've really grown to appreciate the GS-L05's simplicity, and would definitely choose the case again. It's really well made, and I love its warm grooved top and glowing blue front-panel LED.

Serener GS-L05 case
(Source: LogicSupply.com)
The GS-L05 features the world's dinkiest PCI expansion slot, at barely an inch tall! Don't expect to fit a tuner card in there or anything. Get a $100 USB tuner if you want to run sage TV or the like.

The case actually has room for a 2.5-inch hard drive, but I wanted a silent system. I therefore chose Transcend's 4GB IDE flash module (depicted at right), which plugs directly into the board's IDE socket. The downside of that is that you can only use one IDE channel. The upside is that physically, the module is very secure — especially compared to ribbon cable-based IDE-to-Flash module adapters. After getting the heatpipes installed, I didn't want to have to crack the case to re-seat flakey adapter cables.

Okay, here's my whole parts list, with prices:

Via EPIA EX-15000G motherboard with 1.5GHz C7 processor	$270
Serener GS-L05 fanless mini-ITX case	$135
Transcend 4GB 40-pin IDE flash module	$80
Transcend 1GB DDR2-533 DIMM 4-4-4	$70
80-Watt PicoPSU power supply	$45
TOTAL	$600

Initial hardware build

The board installed easily, screwing down on four standoffs in the case. The first step after plugging in the power supply, flash, and RAM was to boot into the BIOS and configure the system so that the power plug itself can serve as the “on” button. Remember, the GS-L05 case eschews such frivolities. I'm not kidding when I say “solid state.” There are no moving parts — not even a power button.

“AC loss auto restart” are the magic words
(Click to enlarge)
The magic involved setting the system to reboot after power failure events — just one of the myriad configuration options in the Via board's truly featureful Phoenix BIOS. I've never seen a BIOS before with so many settings!

The Serener GS-L05 case came with a heatpipe designed for another processor, but with the correct dimensions to fit over the Epia EX board's C7 processor and CX700M(2) chipset. It also included a southbridge heatsink, which of course I did not use.

LogicSupply's GS-L05 case kit for the EX15000G
(Click to enlarge)
First, I removed the stock heatsink, which attached with little spring clips to the board.

Removing the fansink involved squeezing six little plastic spring clips
(Click to enlarge)

Next, I applied a thin layer of conductive paste (which Logic Supply supplied with the case) to the heat pipe, and fastened it to the board with the same six little white plastic spring clips.

Installing the heat pipe was easy
(Click to enlarge)
All that remained was to spread another layer of paste on top of the heatpipe, and screw down the case's lid with the supplied Allen wrench. That's all there was to it; anti-climactic, really.

However, although the photos here don't show it, before attaching the lid I scavenged a couple of switches from an old PC carcass buried in the basement, and connected them to the EX15000's reset and power pin headers. I routed the wires through the hole in the GS-L05 case's tiny expansion slot. I subsequently found the reset button to be essential, at times, for helping the Via board find the flash module. However, the power button really is not needed at all (unless I accidentally reset that BIOS setting!), so I cut off the switch, taped the wire ends together, and stuffed the wires back into the case.

Before attaching the lid, I added crude reset and power buttons (not shown)
(Click each image to enlarge)

In operation, the entire top of the system can get hot, if the system is sitting on something insubstantial like a card table (aka, my “workbench”). Placed on my rock fireplace mantle, though, the system barely gets warm, as the rock provides a nearly infinite heatsink.

With the hardware all put together, it's time to delve into the software.

Installing Debian

I installed Debian Etch (4.0) from a USB key, by following the “easy way” directions found on the Debian website, here. In a nutshell, I copied some system utilities to the USB drive, copied the “netboot” Etch CD image to the key, then booted the system from the key. I won't describe every step, but if you want to get a sense of what's involved, check out Rick Lehrbaum's excellent step-by-step guide, here.

One mistake I made was to opt for an encrypted root filesystem. This is a new feature in Debian, and I wanted to try it out, especially in light of AES acceleration built into newer Via processors. However, it proved to be a mistake for two reasons:

• You have to type the “LUKS” password at boot-time — not practical for a system that may not have a monitor or keyboard attached.
• The IDE flash module can't do DMA, which leads to whole-system slowdowns of half a second or so during write operations, such as during the installation of a new software package. I think the overhead of encryption may worsen this, although I don't really know.

Another questionable decision was to install the full Etch “desktop” — kind of frivolous for a stereo component. Still, it may be nice to have a familiar, easy-to-use GUI, considering that the system is also a living room PC likely to be used by guests and family.

With a basic Debian installation in place, it was time to configure the system for embedded use, and install the applications the system would need to be a music server. Oh, and also time to give the system a name. I called it “4nz,” in homage to my original 2nz box from 1998.

Software tuning and configuration

Flash wears out quickly, supporting between 100,000 and 10,000,000 write/erase cycles. Additionally, it can only be written in large chunks (typically 10KB to 100KB). Thus, a large, slow (non-DMA) write operation can result every time a log file gains a single line of text, for example.

Flash devices that mimick IDE drives (like the Transcend model I used) may have built-in microcontrollers, typically ARM7-based, that apply “wear-leveling” schemes aimed at spreading out writes across the entire drive. Still, when booting from flash, it's best to do what you can to reduce how often the drive gets hit.

First, I edited the /etc/fstab file, adding the “noatime” option to the root filesystem. Otherwise, Linux will try to jot down the time of day whenever any file at all gets read.

Next, I mounted /var/run and /var/log on a ramdisk, since these directories contain files that can get written to pretty often. Looking in /etc/fstab, I noticed that by default, Etch already seems to mount /tmp on a ramdisk, so I just copied the syntax from that entry:


# /etc/fstab: static file system information.
#
# proc /proc proc defaults 0 0
/dev/mapper/4nz-root / ext3 defaults,errors=remount-ro,noatime 0 1
/dev/hdc1 /boot ext3 defaults,noatime 0 2
/dev/mapper/4nz-swap_1 none swap sw 0 0
/dev/ram0 /tmp tmpfs defaults,nodev,nosuid 0 3
/dev/ram1 /var/run tmpfs defaults,nodev,nosuid 0 3
/dev/ram2 /var/log tmpfs defaults,nodev,nosuid 0 3

This appeared to work fine. Of course, ramdisks don't persist across reboots. No biggie, I thought… I can always comment out the ramdisk mount points if I ever need to retain the logs for diagnostics. However, I hit a snag after I installed mpd and apache2 (via “apt-get install apache2 mpd”) — both programs expect their log files to exist, after the first launch. What to do?

After a couple of false starts, I wound up implementing a crude hack to create the expected files prior to launching the applications. Warning: crude hacking ahead! The squeamish may wish to avert their gaze!

First, I edited the symlinks in the /etc/rcX.d runlevel directories to “kill” rather than “start” apache2 and mpd (the README in each of the rcX.d directories explained how to do this). Root's .bash_history file reveals the following:

cd rc2.d/
ls -l
mv S91apache2 K9apache2
mv S30mpd K70mpd
cd ../rc3.d/
ls
mv S91apache2 K9apache2
mv S30mpd K70mpd
cd ../rc4.d/
mv S91apache2 K9apache2
mv S30mpd K70mpd
cd ../rc5.d/
ls
mv S91apache2 K9apache2
mv S30mpd K70mpd

Then I added the following to /etc/rc.local:

mkdir /var/run/mpd
chown mpd:root /var/run/mpd
mkdir /var/log/mpd
chown mpd:root /var/log/mpd
/etc/init.d/mpd start

mkdir /var/log/apache2
chown www-data:www-data /var/log/apache2
mkdir /var/run/apache2
chown www-data:www-data /var/run/apache2
/etc/init.d/apache2 start
exit 0

This creates the expected files on the ramdisk first, before launching mpd and apache. It sure is a crude hack compared to compressing and storing the ramdisks across reboots. Eventually, I'll want to figure out how to do just that, if only so I don't wind up having to edit /etc/rc.local every time I install a new daemon of some kind. However, Linux is a process, not a product, for a hobbyist like me. I prefer to get things working first, and then gradually make improvements as time and interest allow.

With apache2 and mpd installed and reliably starting up each time the system reboots, it's time to give the system access to some digital music files. First, you configure the Infrant device to have a static IP address. Then you set it up to export its /media directory via NFS. Both changes are simple to make, thanks to the device's rich yet ultra-intuitive web interface.

Configuring NFS on Infrant NV+
(Click each image to enlarge)
Next, you add an alias to the mini-ITX system's /etc/hosts file, so that you'll be able to address the NAS server by its hostname (or whatever name you like), as well as its now-static IP address:

cat "192.168.3.253 ammo" >> /etc/hosts

Finally, it's time to configure the mini-ITX system to automatically mount the remote filesystem at boot time.

mkdir /mnt/ammo
cat "ammo:/media /mnt/ammo nfs rw 0 0" >> /etc/fstab

Next, we tell mpd where to find the music files, by editing /etc/mpd.conf to include:

music_directory "/mnt/ammo/Music/mp3"

While in there, you can configure mpd to use Alsa output. The other possibilities are OSS and icecast, an interesting thought if you want to stream your songs out to the Internet.

We're nearly done. Let's install phpMp, still my favorite mpd interface despite having reached perfection (and having seen no updates) since 2003:

apt-get install phpmp

Well, there is one thing left to do. And actually, it's a big 'un.

Compiling a high-definition audio driver

Before our system can actually do digital-to-analog conversion (i.e., produce sound), we have to build an Alsa driver for the “high-definition audio” (hda) sound chip built into our system's CX700M(2) chip. This is by far the most difficult part of this entire project. Frankly, it's a painful process that in an ideal world, might be avoidable.

The process is described pretty well, albeit in broken English, in a weird PDF document distributed with the binary driver bundle, here. Instead of using the laughably simplistic “install” script provided in the bundle (hah!), you'll want to walk through each line manually, fixing errors as they crop up.

In a nutshell, for Debian 4.0 at least, you first have to install gcc and the complete Linux kernel source code tree and headers corresponding to the version in your system, patch up the Linux tree with various binary files, carefully edit several source code files, and then build new snd_hda_intel and snd_hda_codec modules with the Linux source code tree. Root's .bash_history file tells the woeful tale:

apt-get install gcc
apt-get install libc6-dev libc-dev
apt-get install linux-headers-2.6.18-4-686
cat "deb-src http://ftp.debian.org/debian stable main contrib non-free" >> /etc/apt/source.list
apt-get update
apt-get install linux-tree-2.6.18-4
cd /usr/src/
bzip2 -cd linux-source-2.6.18.tar.bz2 | tar xvf -
cp ~/via-linux-audiopackV1.40/alsa-driver-1.0.11/pci/hda/patch_via.c /usr/src/linux-source-2.6.18/sound/pci/hda/
cd !$
vi patch_via.c (various edits or not, depending on kernel version, as explained in "README")
vi a couple of other files -- read the README
cd /usr/src/linux-source-2.6.18
make oldconfig
make (watch output and kill after a minute or so, after deps stage)
make M=sound/pci/hda modules
cp sound/pci/hda/*.ko /lib/modules/`uname -r`/kernel/sound/pci/hda/

Glad I opted for the big 4GB flash module. I went from 40 percent to 70 percent “disk” usage after installing all of that stuff. At least you can delete the kernel source tree when you're done.

For some distributions, like Ubuntu 7.04, you also have to build and install a whole new kernel. For some other distributions, including earlier versions of Debian, you can apparently build the needed modules within Alsa's source code tree, rather than Linux's, which is generally quicker and easier and less disruptive.

It's all somewhat of an ordeal. And, you'll probably have to go through it all over again each and every time you upgrade to a new Linux kernel version. It sure would be nice if someday, Via had the resources to invest in moving sensitive intellectual property to hardware or firmware, so that open source drivers could support its products.

That goes double for Via's video drivers — the stock X.org drivers only support 2D acceleration, so if you want 3D acceleration, you have to actually build new X modules. If you thought the sound modules sounded complicated… no wonder so many people wishing to run Myth or Sage TV on Via boards go with a commercial OS, such as iMedia's $20 MythTV distro for Epia boards.

Heck, even some of Via's proper embedded customers don't bother with the ordeal. I noticed that Zonbu is using normal X.org drivers in its recently launched Zonbox network computer, for instance.

Conclusion and closing notes

At this point, if you got the sound drivers compiled, you have a system that works. Not only does it work, I think you'll find it eye-opening to listen to. Wow! It sounds really, really good… great 3D soundstage, no muddiness when a lot of instruments play at once, and bass that can stop and start on a dime. Never has the bass drum sounded so distinct from the bass guitar!

Here's a beauty shot showing the same lovely phpmp interface running on 4nz's display, and on the N800:

A satisfying sight, and mighty fine sound, too
(Click to enlarge)
A couple of random housecleaning bits worth noting:

• My old 3nz server had a cd player and local storage, and I like to rip cd's by X-hosting a grip session on the Nokia 770 or another Linux system in the house. I'd leave grip configured to rip on insert, and eject when done. For best sound quality, I'd configure grip with lame and the following encoder command line: --preset extreme %w %m. Then, I could just feed CDs in and wait until they ejected, then feed in another, etc. Very convenient. I haven't tried it yet, but I plan on doing something similar with 4nz, except that the CD drive will be in another system, and the “mp3” directory will be NFS-mounted
• As described, 4nz consumes a steady 13 Watts, according to my Kill-a-Watt meter. The Infrant eats 25 Watts, idle. Although it's kind of like ordering a diet soda with your ice cream sundae, I decided to save some energy and try out TNT-Audio's amazing T-Amp. Based on similar Tripath chips to those used by Sonos, this $25 amplifier actually sounds cleaner and more spacious than my Class A Marantz, while drawing 2 Watts instead of 250 Watts. The Marantz can drive four sets of 8 Ohm speakers at high sound pressure levels, which can be nice. But the T-amp combined with $100 eBay speakers sounds better. Much, much better.
• I started this whole project before discovering Real's Rhapsody client for the N800. I believe that Rhapsody is the “killer app,” not only for the N800, but for all small web tablets. Mobile phones someday too, maybe. But I honestly don't know if I would have bothered to build an elaborate NAS-based music system, had I had Rhapsody on the N800. Why even store your own music, really?

In closing, I'd like to thank free software developers for making projects like this possible. Also, I'd like to invite feedback from other stereo computer enthusiasts and professionals, who I'm sure will be able to suggest improvements. Post your suggestions in the talkback forum below, or write to me directly at the address linked to my signature.

—Henry Kingman

---

Do you have comments on this story?

---

Talkback here

---

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.