Redirecting audio to a remote host using esddsp

There are situations where you might want to redirect some audio you're playing on your local computer to another computer's speakers, potentially in a different room, or even anywhere on the Internet.

One of many possibilities to do that is to use the Enlightened Sound Daemon (EsoundD, or esd). It ships with a program called esddsp (apt-get install esound-clients) which can redirect various audio sources.

First, you have to start the esd daemon on a console on the remote host (the one which should output the audio on some speaker, for example e.g. like this:

  $ esd -public -nobeeps -tcp

You can do this as regular user (no need to be root) if you have the proper permissions. You also need to allow connections on port 16001 in your firewall settings. Then you can redirect audio to that daemon from another computer. In this example I'm redirecting some music using various players:

  $ esddsp -s mpg321 -o esd foo.mp3
  $ esddsp -s mplayer -ao esd foo.mp3
  $ esddsp -s ogg123 -d esd foo.ogg

This also works fine for videos, in which case you can redirect the audio (but not video):

  $ esddsp -s mplayer -ao esd foo.mp4

For the video player Miro, I've recently documented this in the Debian package's README.Debian file. Basically you have to edit ~/.xine/config and enable audio.driver:esd there, then start Miro with

  $ esddsp -s miro

Audio will be emitted on the remote host, video remains on your local PC.

Some programs may also support esd natively, in which case esddsp is not required, e.g.

  $ ogg123 -d esd -o host: foo.ogg

coreboot projects for Google Summer of Code 2008

The coreboot project (previously known as LinuxBIOS) is taking part in the Google Summer of Code™ 2008 program. This year, the project has been assigned two slots/students who will work on the following projects:

  • All Virtual All The Time (AVATT):

    This project aims to integrate into the coreboot BIOS a payload consisting of a minimalist KVM-aware Linux kernel along with an initrd image that contains the tools needed for creating and starting guest virtual machines installed on top of it. The resulting system could host any x86(or x86-64) OS that can run over KVM (almost any major OS does), and there is a great challenge to make it as small as possible, so that it can fit in a 2MB flash image.

  • SCSI booting in coreboot:

    Currently coreboot can not boot from an arbitrary SCSI controller. There are two solutions for the problem: (1) Use Linux and Kexec. This requires to keep the SCSI driver in the flash chip. (2) Use x86emu/vm86/ADLO and the int13 method. This would allow to use the PCI option rom available on all modern SCSI controllers. So we obviously need a solution based on the latter. This could as well be implemented as a Linux program, as an intermediate payload, or as a shared library. At this point of time, I would like to implemente it as a daemon program. The program needs to catch the int13 interrupt vector that the SCSI option rom installs and make it available to arbitrary (firmware/payload) code trying to load something from disk.

This should make for an interesting summer with nice improvements for coreboot.

Resizing a dm-crypt / LVM / ext3 partition

I've bought a new hard drive for my laptop recently, because I finally got fed up with my constantly-full disk. Having to browse around in $HOME looking for stuff which can be safely deleted just because I want to run fetchmail (and that would fill up my disk) just sucks. So, after getting a cheapo 160 GB 2.5" disk (the old one was 80 GB), I had to move all my data to the new disk.

As I didn't want to re-install from scratch I started with dd'ing the whole disk over to the new one (using a live CD and an external USB hard-drive enclosure). This took pretty long, but went fine otherwise.

The new disk then contained all my partitions (hda1-hda3) and also GRUB in the MBR etc., as expected, but was still only 80 GB in size, of course. So the first step is to enlarge the hda3 partition, which is a dm-crypt volume that contains various LVM logical volumes (for /home, /usr, /var, swap, etc.), each of them using the ext3 filesystem (except for the swap volume, of course).

0. Perform backups, boot from a live CD

Important: If you plan to perform any of these steps, make sure you have recent backups! I take no responsibility for any data loss you might experience. You have been warned!

First off, you should boot from a live CD which has all the tools you'll need, including cryptsetup, LVM tools, resize2fs, etc. You can use the nice grml live CD for instance.

1. Resize partition

This sounds scary (and it is!), but the way I enlarged the encrypted hda3 partition was by first deleting it via fdisk. First, issue the "p" command in fdisk, write down the exact start cylinder of hda3. Then delete hda3. Now create a new hda3 partition which starts at exactly the same cylinder as the old hda3 but is larger, i.e. in my case it has ca. 80 GB additional space.

Your data will still be there if you don't screw up, and the partition is bigger now. Using something like gparted will likely not work as expected, as the partition is encrypted!

2. Resize dm-crypt volume

Nothing to be done, it seems dm-crypt automatically adapts and notices that the partition is bigger. Just "open" the encrypted volume using cryptsetup now:

  $ cryptsetup luksOpen /dev/hda3 foo

3. Resize LVM physical volume

Next step is to tell LVM about the new space. We first resize the LVM physical volume on the foo "partition" to use up all newly-available space.

  $ pvresize /dev/mapper/foo

4. Resize LVM logical volume

Now we can pump the new space into any of the logical volumes (or into multiple ones). I only increased one logical volume, my /home:

  $ lvresize -L +74 GB /dev/vg-whole/lv-home

5. Resize ext3 filesystem

The final step is to resize the ext3 filesystem on the lv-home logical volume (after running the obligatory fsck -n). I first used ext2resize, but that failed horribly:

  $ fsck -n /dev/vg-whole/lv-home
  $ ext2resize /dev/vg-whole/lv-home
  error: Invalid argument: seeking to 3258921205760

This seems to be a known bug, ext2resize apparently cannot handle large disks or something, and as I found out a few minutes later it's pretty much deprecated anyway. The better solution is to use resize2fs:

  $ fsck -n /dev/vg-whole/lv-home
  $ resize2fs /dev/vg-whole/lv-home

That's it. We can now reboot the system from disk and enjoy ca. 80 GB of additional hard drive space. Yay!

Building custom Debian live CDs with live-helper / live-magic

live-magic settings
live-magic building an ISO

If you want to generate a custom Debian live CD, including only the tools you want (and maybe additional tools you don't find in other live CDs) there's a really simple solution: live-helper.

Creating a basic bootable Debian live CD ISO image in the current directory is as simple as:

  $ lh_config
  $ lh_build

That's it. The result will be a file called binary.iso, which you can either burn on a CD-ROM via

  $ wodim binary.iso

or test in QEMU using a command line like this:

  $ qemu -boot d -cdrom binary.iso

Of course there are many possibilities to customize the generated image to your likings, see the documentation in the Debian wiki, or the lh_config/lh_build manpages.

Please note that live-helper can not only generate CD ISOs, but also bootable DVDs, images for USB thumb drives, or netboot images.

There's also a nice GUI called live-magic which will make the process a bit easier if you don't like doing things on the command line.

Google Summer of Code 2008 Student Application Deadline postponed

Just FYI: The student application deadline for this year's Google Summer of Code has been postponsed to Monday, April 7, 2008.

So, if you've been thinking about applying as a student for one of the many, many accepted open source projects (Debian, Linux, NetBSD, subversion, vim, or coreboot — just to name a few) you still have a few days left...

Syndicate content