Sennheiser HD515 vs. Shure ES210


I just started playing around with my new earphones, purchased at the recently remodeled Apple Store Eastview with my iPhone rebate. I grabbed a pair of Shure ES210 earphones to use at work for isolating myself from the disgusting bodily noises eminating from the surrounding cubicles and they sound fantastic. This is my first pair of in-ear earphones and I have to admit, I'm impressed. I had been hearing for a while that people were getting amazing levels of noise isolation with ear canal headphones but I wasn't completely convinced until I put the E210s on.

At the moment, I just have the earphones plugged into my PowerBook where I've got a smart playlist in iTunes with every lossless track on shuffle. The intro to Dark Side of the Moon really makes you think you're going insane when the sound is inside your head. The background noise from the PowerBook's sub-par audio chips is a bit annoying, but it doesn't seem to be nearly as present as it is with my HD515s.

I really don't have much else to compare them to other than my Sennheiser HD515s so I guess I'll do that. From HeadRoom's frequency response graph, you can see that they're two very different listening experiences. The ES210 earphones really are much closer to monitor headphones as they have a very flat response across most of the lower frequencies whereas the HD515 headphones add a lot more "personality" to the sound, which I've really grown to like. I was surprised that the noise isolation of the ES210 wasn't much better than the HD515. The earbuds are certainly a different type of isolation and, in some respects, better (no bulky cans hanging off my ears) than the HD515 but I have a feeling that they're about on par with the level of noise that they block out. I'll definitely need to try the ES210 out in some noisier conditions before I make a final judgement though.

Overall, I'm really enjoying the ES210 simply because I get a very high quality sound reproduction without having to carry around giant cans. Now I just need to find a better source... Does anybody know where I can get a decent Sony Discman?

Lights out without a LOM


From the first time I played with the LOM (Lights Out Management) interface on a Netra, I've wanted a way of getting that functionality on all of my boxes. I've found that by making use of a serial port, wake on lan, and a TFTP server, you can get similar functionality without breaking the bank. This guide assumes that you're attempting to boot x86 hardware with PXE/Wake on Lan support and are using OpenBSD for the netboot server. I'll try to point out any significant differences between OpenBSD and other Linux/Unixes.

First, record the MAC address of the system you want to work with, you'll need this later for DHCP and Wake on Lan. The easiest way to get the MAC is to run /sbin/ifconfig or /sbin/ip link but if the box isn't running or doesn't have an OS installed, you can pop the cover off and read it off the NIC. Or for the extremely lazy (myself included) you can have the box attempt to PXE boot and watch your DHCP server logs.

Next, setup your TFTP server by creating /tftpboot and uncommenting the appropriate line in /etc/inetd.conf. Restart inetd. Depending on what hardware you're booting and what you want to install/boot, you need to add the proper files to your /tftpboot directory. I keep a number of different kernels/bootloaders on my TFTP server so that I can boot just about any hardware I come across with any distro I want.

Let's assume that you want to install Debian on an x86 box. The Debian folks have been nice enough to create a tarball of everything you need to get going on a TFTP server. Just grab /dists/stable/main/installer-i386/current/images/netboot/netboot.tar.gz from your nearest Debian mirror and unpack it in /tftpboot. In the event that the tarball isn't available for the branch or distro you want, you'll need at least a pxelinux file and a kernel. Other files may be necessary depending on the distribution. Check your documentation for details.

Now you need to add a section to your /etc/dhcpd.conf so that the filename and location of the TFTP server is given to the PXE bootloader when it broadcasts for DHCP.

host netboot { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address; filename "debian/i386/pxelinux.0"; next-server; }
The first line defines that this is a specific host. The name isn't really important here unless you've got dynamic DNS setup and that's outside the scope of this article. For now, just pick something that tells you what this section is so that you know what it does when you come back to it later. Fill in your MAC address in the hardware ethernet line so that the DHCP server knows what host we're talking about. The fixed-address line is only necessary if you want this host to always get the same IP assigned to it. If not, you can leave this out, but make sure you've got a dynamic range setup elsewhere in your dhcpd.conf. The filename line tells the client where the PXE code to run is relative to your /tftpboot directory. I keep a number of different images for various distributions and architectures on my server, so all of my boot images are organized by <distro>/<arch>/file. In some cases, paths for config files and whatnot are hardcoded into the PXE loader and I resort to symlinking to various files. Finally, the next-server line tells the client which TFTP server to connect to to download the image.

Once you've saved and reloaded your dhcpd.conf, your box should now boot on the console assuming that the BIOS is configured to allow PXE booting. Double check that it grabs a configuration from DHCP and downloads the image from the TFTP server. Once this is working, you're ready to move on to the serial port.

This is where things really deviate depending on what distro you're trying to boot. I'll do my best to cover as many scenarios as possible.

Syslinux (pxelinux)

Add a line that looks like this to your pxelinux.cfg file:

serial 0 9600
Where 0 is the COM port you want to connect to and 9600 is the speed. Unless you've got a good reason, I wouldn't set the speed faster than 9600 baud. While this isn't a rule, it's a bit of a standard that if you plug in a serial console with 9600-8n1, things should work.


Add the following lines to your /boot/grub/menu.lst

serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1 terminal serial
It is advisable to setup a boot password on the serial port because if someone were to compromise your serial console, they'd be able to boot into single user mode and gain root access to your system. Generate a password hash by running md5crypt at the grub prompt and adding the following to your menu.lst

password --md5 <hash>


Add the following line to your lilo.conf to enable serial console access. Once again, a password is advisable.



The BSD bootloaders are a bit different than LILO and GRUB. They tend to resemble OpenBoot in some ways, making complicated configurations not so complicated. OpenBSD's pxeboot will attempt to download boot.conf from your TFTP root for additional configuration information. It'll still work if this file doesn't exist. Create /tftpboot/boot.conf and add the following line to it:

set tty com0
This will switch the bootloader's interface to the serial port, giving you complete control of the system. No additional changes are needed because the BSD kernel will get it's console configuration from the bootloader. Your system should boot and be happy.

Linux Kernels

Depending on the kernel you're booting, you may also need to specify a serial console in the kernel arguments by appending the following to the kernel command line.


If you boot the system now, you'll be able to see kernel messages scroll by as the system boots. Depending on the userspace setup, you still may or may not get a terminal. If not, you'll need to find a way to add the following line to /etc/inittab

co:2345:respawn:/sbin/getty ttyS0 CON9600 vt102

Once your system is installed and running, you may have to tweak the installed bootloader and/or userspace to get the serial console working again. This probably seems like a lot of extra work without much gain, but once you've done it a few times, it becomes second nature and the benefits of running the system on a serial console are apparent.

The last piece of the puzzle is Wake on LAN. WOL works by having the NIC watch for a 'magic packet' on the local link while the system is powered off (ATX power supplies provide 5 volts to the motherboard in the off state for just this sort of thing). When the magic packet is received, the NIC sends a wake up event to the motherboard which relays it to the power supply as if the power button were pushed. You may need to enable these features in the BIOS and/or network card configuration. Not all cards support PXE booting and others do, but call it something different. If in doubt, Google for the model of the card.

In order to send the magic packet, you need to have at least one machine already running on the network segment. There are dozens of scripts on the net for sending out Wake on LAN packets, but because I'm a Python advocate, I tend to prefer this one. Create a .wake_hosts file in your home directory with one host on each line in the format:

<hostname><tab><mac address>
Put the wake script in your PATH and run wake to send out the magic packet. If all goes well, you'll see your serial console come to life.

While the serial console may not be practical for system installs, netbooting certainly is. But once you've got everything running, the serial console can be an invaluable tool in case you manage to lock yourself out of the system by crashing sshd, adding a bad rule to iptables, messing up the routing table, installing a bad kernel, or losing the root password. This approach is limited in comparison to a LOM in that you don't get direct access to the BIOS or more complete diagnostic tools without setting up something like memtest86.

A word on security; in most cases, adding another avenue of access to the system that is not necessarily needed is considered bad security practice. However, by installing a boot loader password and securing your terminal server, the chances of a successful attack through the serial console are probably on par with running an SSH daemon. Even if it does provide a secuity hole, I believe the benefits of having a lifeline like this outweigh the risks.

MythTV Protocol Library: HD on a PPC Mac mini


I've been playing around with the mythproto code recently, not so much implementing protocol commands, but building applications on top of the basic ones that have already been implemented. Anybody that has taken a look at the source repository has probably seen the module. This was not ever meant to be a usable piece of code, but more of a way for me to test new commands without having to constantly rewrite a test method.

However, I found that the frontend module has been extremely useful in playing back HD content that the official MythFrontend has problems with. For instance, when frames are dropped from the MPEG source, MythFrontend tends to lose audio sync. Usually, this isn't very noticable but it can accumulate over the course of a show and become unbearable. The official frontend also, until a recent patch, didn't support digital audio output on OS X, a major annoyance for someone like me with an external DTS decoder connected to my Mac Pro. These problems can be avoided by using VLC as a video player instead of the builtin MythFrontend one. VLC keeps the audio synced surprisingly well and it takes a lot more pushing to make it loose sync than anything else I've seen (I also tested mplayer for this purpose). VLC also supports digital audio output right out of the dmg, no configuration needed.

Over the weekend, I moved my Mac mini and one of the 20" displays into my bedroom to replace ye olde TV with something a bit more... hackable. To my dismay, I found that the PowerPC mac mini just doesn't have the CPU power needed to decode a 18 Mbps MPEG-2 stream in realtime. After a few days of thinking on the problem, I decided that I could transcode the video to a less CPU intensive format and stream it from there. I didn't want to keep two copies of everything on the backend, as that would be a waste of disk space (and causes the CPU on the myth box to spend all of it's time transcoding). Instead, I'm running mythproto's myth.frontend module on the Mac Pro, that feeds the stream into VLC with these obscure options --sout "#transcode{vcodec=mp2v, vb=1500, venc=ffmpeg, scale=0.5, acodec=mp3, ab=192, aenc=ffmpeg, threads=2 }:standard{access=udp, mux=ts, dst= }" - 2>&1 >>/tmp/mythproto.log in order to transcode the video to MPEG-2 at half the resolution and stream it to the mini. The key here is that the video is scaled to half resolution, the rest of the options are just tweaks for quality. The end result is that I fire up VLC in UDP listener mode on the mac mini and pop it into fullscreen with fairly impressive results. While I can tell the difference between the transcoded video and full resolution HD up close, it's nearly impossible to tell them apart from across the room. VLC chews up about 120% of the CPU (out of a possible 400% due to four cores) on the Mac Pro to decode and repack the video in realtime, not bad considering that it takes about 110% of the CPU just to decode and view HD locally on the Mac Pro. On the Mac mini side of things, it takes a mere 30% of it's CPU to decode and play the stream in realtime, leaving plenty of room to add more interesting functionality.

In the course of making this hack work, I started to think that it would be a good idea to write a MythTV plugin for VLC. This would offer easy setup and good integration without having to write a new video player. Expect to see more in this direction soon.

Also worth noting... I added auto commercial skip support to the frontend module shortly after I got the mac mini stream going. Without an easy way to skip around the stream, I found this to be a very useful feature. Commercial skip hasn't been tested much yet, so it may not work completely. Worst case: You end up sitting through a few commercials for poorly targeted products (Who puts tampon commercials on Spike's TV for men?).

MythTV protocol library updates


I've begun documenting the MythTV protocol in detail in a wiki. It's far from complete, and is probably more incomplete than some of the other protocol references on the internet. However, I do have about 70% of the protocol figured out and documented in comments in the library. If you know a little bit of Python, you can probably figure out everything you need from the code.

Note that this is not the final protocol API, only the initial structure. I am planning to write some object oriented wrappers around the protocol after I've got all of the commands implemented.

Protocol reference - Wiki Protocol implementation - Repository

If you've got questions or comments, send me an email: synack <at>

MythTV Protocol Library


Over the past few months, I've been working on a Python module that can interact with a MythTV backend. A few days ago, I hit a milestone by successfully streaming a recorded video from the backend, through a Python script, and into MPlayer.

I've since switched to using VLC because it supports passthrough of AC3 audio to the digital audio output on my mac pro and appears to have less trouble keeping the audio synced with the video than MPlayer did.

In the process of writing this module, I found that there was very little documentation on the MythTV protocol. I don't know for sure, but I'd guess that the protocol isn't documented because the developers aren't planning on sticking with it in the long term. MythTV's Future Development page suggests that the protocol be changed to something more standard and efficient. As much as I'd like to see this happen, I haven't the skill or patience with QT to design and implement a new protocol for MythTV that everybody can agree on. So, as an interim effort, I decided to document and implement a library for the protocol to make the existing protocol more accessible.

I've still got about 25 more commands to implement before I can start moving toward a more abstracted API for developers. At the moment, the frontend module is purely proof of concept and is more of a way for me to test the functionality of the protocol implementation.

Once I'm done implementing all of the commands (not just the ones required for a frontend), I'll begin working on a more acceptable interface for object oriented programming. Eventually, I'd like application code to look something like this: import myth.client

frontend = myth.client.MythFrontend('server address', 'client name')

frontend.scheduleRecording(title='Battlestar Galactica', channel=52, commflag=True, priority=5)

for conflict in frontend.getConflicts(): if conflict.getTitle() == 'Battlestar Galatica': print 'Oh noes! You need another tuner!'

for recording in frontend.getRecorded():
    if recording.getTitle() == 'The Simpsons':

If you're a programmer, you can probably see what I'm getting at. My goal is to make it as simple as possible for someone to pick up an API reference and start writing cool applications that use MythTV as a source of information. For instance, Freevo could be modified to use MythTV as a backend, or a web app that streams from MythTV in a Flash object using little more than XMLHttpRequests, or a program that sends you a text message if there's a scheduling conflict. There are lots of possibilities.

Until I've settled on an API, I would recommend that you refrain from writing code that depends on the myth module, (I haven't even decided that that's what I'm calling it). However, I'd be more than happy to take patches or some time in an IRC channel with a MythTV developer that knows the protocol.

Let me know if you're interested in using this module by leaving a comment or emailing me. I'm curious to see what other people are planning to do with it.