Tagged: linux

These blog posts have all been tagged with linux. These tags appear to be related:

09 Dec
Start XBMC from remote

The Android XBMC Remote app has a "Power on" button. This button sends a wake-on-lan (WOL) packet to the XBMC server, so that it can wake up. However, my XBMC server runs all kinds of server stuff, so I don't want to let it sleep. Still, XBMC uses more than 10% CPU power even when it's in idle, so I don't want it running all the time either.

I've written a small Python script that executes a command every time it receives a WOL packet. This is then used to start XBMC.

Click for the source code...

11 Dec
Duplicating audio with ALSA

threesixtyfive | day 230

On Linux the most used sound system is the Advanced Linux Sound Architecture, ALSA for short. It's a very configurable system, but it's not easy to dig down far enough to get to its power.

What I wanted to do was to get the same music in the living room and the computer room. The rooms are right next to each other, and my desktop is sitting with its back towards the living room. My desktop has two audio cards, one built-in VIA-82xx and my trusty SB Audigy. All I had to do hardware-wise was to connect the VIA-82xx to the amplifier in the living room and the Audigy to the amplifier in the computer room.

But then came the tricky part - to have one application send its sound to both cards simultaneously. You can configure this on a per-user basis in ~/.asoundrc or globally for the entire system in /etc/asound.conf. It takes two steps:

  1. Create a virtual "sound card" that has four channels. Channels 0 and 1 will be sent to one sound card, and channels 2 and 3 will be sent to the other.

  2. Create a routing "sound card" that mixes its stereo input to the quad-channel virtual sound card.

Place this into ~/.asoundrc or /etc/asound.conf:

  # This is the four-channel card that sends its first two channels
# to one real card, and the other two channels to the other card.
pcm.tworooms {
    type multi;
    slaves {
        a {
           # The first real card, change to "channel:CARD=CardName"
           # for your system.
            pcm "front:CARD=Audigy";
            channels 2;
        b {
           # The second real card, change to "channel:CARD=CardName"
           # for your system.
            pcm "iec958:CARD=VT82xx";
            channels 2;

    # This configures how the four channels of this virtual
    # card are distributed amongst the real cards.
    bindings {
        0 { slave a; channel 0; }
        1 { slave a; channel 1; }
        2 { slave b; channel 0; }
        3 { slave b; channel 1; }

# This virtual "sound card" mixes two channels up to four.
pcm.both {
    type route

    # Its four-channel output is sent to the "tworooms" device.
    slave {
        pcm "tworooms"

    # This defines how the channels are mixed. Input channel 0 is
    # sent for 100% to channels 0 and 2 of device "tworooms",
    # and its channel 1 is sent for 100% to channels 1 and 3.
    ttable {
        0 { 0 1.0; 2 1.0 }
        1 { 1 1.0; 3 1.0 }

So far so good. Now I want surround sound. Unfortunately, when I change slave "A" to surround51:CARD=Audigy and increase its channels to 6 (updating the bindings accordingly) it refuses to work. MPlayer tells me The number of output channels must be between 1 and 6. Current value is 8.

If you know how to solve this, please let me know. ALSA should support more than 6 channels, as demonstrated in the ALSA wiki.

31 Mar
Cleaning up an Ubuntu system

Shining skies

Ubuntu uses quite a nifty package manager. It keeps track of which file belongs to which package. Not only that - it also keeps track of which packages you requested, and which were installed as a dependency.

The package manager can remove unused dependencies automatically. And this is what we'll be using to clean up your Ubuntu system. You see, you can mark packages as installed automatically, even if at some point you requested them yourself. By marking them as "automatically installed" you can be sure that they are only removed when they really aren't needed any more. Here's how it's done:

  1. make a list of manually installed packages:

          aptitude search '~i!~E' -F '%M %100p' | grep -v ^A > manual_to_auto
  2. edit the file and remove from the file the packages you want to keep.

  3. read through the manual_to_auto file again to see whether you can afford to remove the packages that are in there.

  4. mark all packages that you left in the file as "automatic". This will show a list of packages that will be removed and give you a chance to review the changes and bail out before anything harmful happens. Feel free to abort, re-edit the manual_to_auto file and try again until you're happy

          sudo aptitude markauto $(< manual_to_auto)
  5. Be happy with the free space. I've freed up 1 GB on one machine and 500 MB on another with this method.

I suggest you remove at least the following packages from the manual_to_auto file:

  • linux-generic

  • linux-image-generic

  • linux-restricted-modules-generic

  • ubuntu-standard

  • ubuntu-minimal

  • ubuntu-keyring

  • the ....-desktop packages

Be careful; if you're in doubt, remove the package from the list. Everything that you remove from the file will be kept as "manually installed".

If you find out that you removed too many packages, you can simply reinstall the ones you need. Since we haven't purged the configuration files (see below) they should simply work as before when you reinstall them.

I've used information from various sources. However, most of them fail on long package names like linux-restricted-modules-2.6.24-23-generic, because by default Aptitude only shows the first 30 characters of the package name. I also feel more comfortable having a file that I can edit and review before actually marking any packages.

Another cleanup step can be performed by removing all configuration files that belong to uninstalled packages:

  dpkg -l | grep ^r | awk '{ print $2 }' | sudo xargs dpkg --purge

Be warned: this command does not ask for any confirmation. Don't come crying to me when it runs off with your girlfriend.

08 Jan
Bridged networking in KVM

One of the advantages of VMWare is that it has easy to set up bridged networking. However, I love Open Source so I started to experiment with KVM, the Kernel-based Virtual Machine.

Setting up bridging is a bit daunting, but not that complex once you've gotten the hang of it. I placed everything in a script for easy invocation. One of the features I wanted was that ending the script should tear down the bridged network, even when pressing Ctrl+C. This is my script:

  #!/bin/bash -x

if [ "$USER" != 'root' ]; then
    echo "Restarting as root"
    exec sudo "$0" "$@"

brctl addbr br0
brctl addif br0 eth0
ifconfig eth0 promisc up
ifconfig br0 netmask
route add default gw br0

function restoreNet {
    ifconfig br0 down
    brctl delif br0 eth0
    brctl delbr br0

    ifconfig eth0 netmask
    route add default gw eth0

trap restoreNet EXIT

kvm \
    -localtime \
    -hda kvm-xp.qcow \
    -m 512 \
    -usb -usbdevice tablet \
    -net nic \
    -net tap \

Some of the features are:

  1. It starts bridging eth0 and the virtual machine's network. This means that the VM can do a DHCP query and get an address from my DHCP server, for instance.

  2. The bridge is always removed when the script ends.

  3. The mouse simulates a tablet. This allows for absolute positioning, which you'll notice allows your mouse to transparently move between your host system and the VM.

  4. Any commandline arguments you give to the script are passed to KVM.

  5. To create and remove the bridge, the script needs to run as root. If you didn't run it as root, it automatically uses sudo.

Things you'll probably want to edit:

  1. My desktop uses a fixed IP address, replace that with your own IP address.

  2. My gateway has IP address, replace that with your gateway/router address.

  3. My desktop uses eth0 to connect to the network. If you use another device, replace it.

  4. I use this setup to run Windows XP in KVM. The Windows installation is stored in kvm-xp.qcow, replace that with the harddisk image you want to use.

Enjoy! If you have any questions or remarks, post a comment below.

24 May
Selecting NVidia screens on commandline

NVidia has a nice program to manage display devices like monitors, TVs etc. I've used this often to play movies on my PC and watch them on our big wide screen LCD TV. What I wanted to do, is automate switching between monitor and TV. The final goal is that I can push a button on a remote to switch the output. Hey, I'm a software engineer, I automate things.

The easiest way to do that would be two write a shell script that can perform the switch for me. NVidia has be so kind as to provide us with software that can do that. It's nv-control-dpy, packaged in the nvidia-settings source, combined with xrandr.

Here is a step-by-step guide of how I managed to get things running.

  1. Hook up your TV if you haven't done so.

  2. Let X detect the TV:

          nv-control-dpy --probe-dpys
    nv-control-dpy --build-modepool
  3. Tell X to include the TV in the current set of displays. You do this by getting a list of numbers from nv-control-dpy --get-associated-dpys:

          Using NV-CONTROL extension 1.14 on :0
    Connected Display Devices:
      CRT-0 (0x00000001): Acer AL1906
      CRT-1 (0x00000002): SAMSUNG
    associated display device mask: 0x00000001

    Add the two (0x...) numbers together and include them in the next call:

          nv-control-dpy --set-associated-dpys 0x00000003
  4. Add a metamode so that X knows which device to enable/disable. The above command gave you the names and numbers of the display devices - they could be TV-0, CRT-1, DPY-4, etc. To enable the device, set it to "nvidia-auto-select". To disable a device, set it to "NULL". Here is the command that I gave to disable my Acer monitor and enable my Samsung TV:

          nv-control-dpy --add-metamode \
                'CRT-0: NULL, CRT-1: nvidia-auto-select'
  5. The last step is to tell X to actually perform the switch. You use the xrandr command for this. First, get a list of possible resolutions using xrandr:

          Screen 0: minimum 320 x 240, current 1280 x 1024
    default connected 1280x1024+0+0 0mm x 0mm
       1280x1024      50.0*    51.0
       1280x960       52.0
       1280x800       53.0
       1280x768       54.0
       1152x864       55.0     56.0
       1152x768       57.0
       1024x768       58.0     59.0     60.0
       832x624        61.0
       800x600        62.0     63.0     64.0     65.0
       800x512        66.0
       720x450        67.0
       700x525        68.0     69.0
       640x480        70.0     71.0     72.0
       576x384        73.0
       512x384        74.0     75.0
       400x300        76.0
       320x240        77.0     78.0
       1360x768       79.0
  6. The last resolution in that list is the metamode we just added. To switch to it, use xrandr -s resolution@refreshrate:

          xrandr -s 1360x768@79

To switch back, use the same xrandr -s resolution@refreshrate trick, in my case xrandr -s 1280x1024@50

Once you've figured out the names of the devices, the bit masks and the meta mode lines, you can of course place the commands in shell scripts and really get to automate stuff. I'll leave that as an exercise for the reader.