fuzzix

The Latitude C640 isn’t a bad little business machine – while by no means the latest and greatest, its 1.7GHz P4 and Radeon 7500 is plenty to handle any desktop task as well as many games. It also runs GNU/Linux without any major hassles at all… Just don’t use it on your lap as the base can get very hot!

I installed Slackware as this, through a series of bizarre gardening accidents, is the distro I’m most familiar with. I can’t report any problems with the default install, although I do recommend installing the bareacpi kernel from the CD-ROM to make sure your desktop’s battery monitor and other power features function correctly. The 2.6.13 kernel in /testing should support the same features.

Radeon 7500:
You will need to edit the /etc/X11/xorg.conf file to add support for the Radeon card. Be sure the “Module” section includes:

    Load "GLcore"
    Load "glx"
    Load "dri"

…add this “Device” section if a similar one doesn’t exist…

Section "Device"
    Identifier "ATI Radeon 7500"
    Driver "radeon"
    VideoRam 32768
EndSection

…create a “Monitor” section…

Section "Monitor"
    Identifier "Dell Monitor"
    HorizSync 31.5 - 90.0
    VertRefresh 59.0-75.0
EndSection

…then add these devices to the “Screen” section…

    Identifier "Screen 1"
    Device "ATI Radeon 7500"
    Monitor "Dell Monitor"
    DefaultDepth 16

    Subsection "Display"
        Depth    8
        Modes    "1400x1050" "1280x1024" "1280x960" "1024x768" "1152x864" "800x600" "640x480"
        ViewPort    0 0
    EndSubsection
    Subsection "Display"
        Depth    16
        Modes    "1400x1050" "1280x1024" "1280x960" "1024x768" "1152x864" "800x600" "640x480"
        ViewPort    0 0
    EndSubsection
    Subsection "Display"
        Depth    24
        Modes    "1400x1050" "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480"
        ViewPort    0 0
    EndSubsection

I chose a default colour depth of 16-bit as GL performance is better. Add the elements defined above to the “ServerLayout” section…

    Screen "Screen 1"

…and finally, set permissions for DRI so all users can take advantage of it.

Section "DRI"
    Mode 0666
EndSection

You can now run xwmconfig to choose a desktop (if running Slackware) and run ’startx’ to, er… start X. Try running glxgears from a xterm – you should see about 1000 FPS with this setup.

Wi-Fi:
There is no wireless NIC included with this laptop but luckily there are various PCMCIA options available. The MadWifi project maintains a module for Atheros based cards – this module relies on a proprietary library. There’s also NdisWrapper which can cleverly use MS Windows drivers for a wide range of cards under Linux. My preferred option was to use a RaLink based card (thanks to Liam Bedford for the pointer) – the Free Software Foundation has published a list of cards based on the RT2500 chipset and the rt2×00 project maintains a module which is fully licensed under the GNU GPL.

I chose an Asus WL-107G 802.11g PCMCIA card, as it was the first one I managed to find in Dublin City Centre… Under Slackware’s default 2.4.31 kernel there were no difficulties compiling, installing or loading the current beta rt2500 module from the rt2×00 project (I didn’t bother trying the driver included on the CD). The included RaConfig2500 frontend makes connecting to available networks very simple – click “scan”, select a network, click “connect”. The frontend’s only dependency is Qt. If the DHCP client deamon isn’t running then you won’t automatically obtain an IP address from the connection. You can run it as root from the command line as follows:

# /sbin/dhcpcd -t 60 -d ra0

Under the 2.6.16 kernel I had less luck with this module (kernel panics) so I tried the newer rt2×00 module. This is a complete rewrite of the rt2400 rt2500 and rt2570 drivers rolled into a single module. I think it was decided to do this because they contain a lot of common code. Unfortunately I had no luck with this one either. Another look at the website revealed CVS downloads for all modules which are tarred up on the hour. I downloaded the rt2500-cvs-2006032011 module and watched it function as smoothly as the beta did under 2.4.

Kernel Considerations:
Just a few notes to help you if you decide to compile a kernel:

Enable Dell Loptop Support – allows you to check on CPU temp etc.
PCMCIA: 32-bit Yenta bridge support should be sufficient.
ACPI: AC Adapter, Battery, Button, Fan, Processor, Thermal Zone.
IDE: Build in the Intel PIIXn driver for DMA support.
Networking: Enable Wireless LAN drivers & Wireless Extensions to use Wi-Fi. The on board Ethernet chipset relies on the 3Com 3c590/3c900 series module.
Graphics: I recommend compiling in the VESA framebuffer driver if you want a full screen TTY. The Xorg radeon module takes care of everything else.
Sound: The an board card uses the Intel/SiS/nVidia/AMD/ALi AC97 Controller ALSA module.

Conclusion:
Installing GNU/Linux on this laptop provided no major headaches. The minor hiccup with the RT2500 based Wi-Fi card with the 2.6 kernel wouldn’t affect my recommendation of it at all – it’s a fine card and seems to work well on every connection I’ve tried it on. All in all a good choice for the penguin fan.

The Really Esoteric, Nerdy Bit At The End:
In the quest to make every piece of hardware look wonky in some way I adopted the Dvorak keyboard layout some time ago and really like hardware that makes switching keycaps simple. So, how to do Dvorak on this laptop…

Pros: The housing for each key is the same. The keys come off quite simply. The keys are all the same shape.
Cons: Track stick.

The track stick is what you’ll hear some people call the “nipple” – it’s the little mouse pointer dealy in the middle of the keyboard. You have a couple of options when it comes to moving keys around. One is to leave the track stick as is and use a Dremel or similar to shave off the corners of the keys that will sit around it or you can simply remove the track stick. I went with the latter.

The Dell website contains instructions for removing the keyboard – follow them.

After you’ve done this pull the keyboard connector plug out of the board. You can remove the top of the connector by gently pulling out the tabs on either side of the plug and prising it off with a screwdriver. When you’ve done this remove the ribbon cable for the track stick and replace the cover making sure the keyboard ribbon connector is positioned correctly. Now pull the rubber cap off the track stick. Peel off the sticker at the back of the track stick’s board and remove the four screws holding the board in place. It should now be totally free of the laptop, ready to gather dust in a big box of bric-a-brac labelled “spares” we all fool ourselves into thinking will be useful one day. It might be an idea to place the track stick, its cap and the screws an a small bag in case you pass the machine onto someone else some day – they should be simple enough to refit. Finally, plug the keyboard connector back into the board and replace the keyboard, its screws and the hard disk. Now rearrange the keycaps as you wish.

We all know that WMA is as evil (like Dante meets Bosch in a crack lounge </Brass Eye>) but the fact is it’s out there. What do you do if you’re handed a WMA file? You could transcode it, but transcoding music is also evil and I can do without double-evil hanging over my day.

I’ve been handed WMA files by friends and have played them satisfactorily (well, as satisfactorily as WMA will allow…) with beep-media-player and xmms using xmms-wma, but recently I started using amaroK. While the xine backend plays the file, it fails to be added to the amaroK music library as TagLib has no support for WMA.

Doing a little research I stumbled upon Umesh Shankar’s WMA Support for TagLib – a version of the TagLib metadata library with support for WMA. Replace your current version of TagLib with this one, strap yourself in and feel the Gs as amaroK imports your WMA file’s metadata with impunity! Cor!

TagLib, unfortunately, does not offer support for M4A/AAC tags but never fear – it’s coming. I noticed while compiling what will become amaroK v1.4 from SVN that MP4 tagging support is included with the help of MP4v2 or FAAD2. This new version will also feature gapless playback with the xine engine – schweet…

Well, since I was asked…

This post should hopefully fill you in with a basic idea of what’s required to stream your own online radio station. This is not intended as a thorough explanation – some experience is assumed (eg, being able to install software). The purpose of this post is to go through the bare essentials.

What you’ll need:

• Icecast
• Ices (requires libshout)
• Ogg-vorbis (Your distro probably already has this)
• A media player, such as amaroK

Overview

The server consists of two main components, the streaming server (Icecast) and the source client (Ices). Icecast streams the audio to your listeners and Ices provides the encoded audio to stream. For my setup I run Icecast on my “always on” server box and Ices an my desktop, but you can run them both on the same machine. Icecast has very little processing overhead and Ices shouldn’t interfere with most desktop tasks (It runs in about 10-15% cpu on my Athlon 1800+). They both use fairly simple XML configuration files which are well commented.

Icecast

On the server side I created a directory called .icecast/ in my home directory to hold configuration data, web templates etc. A sample template/configuration should be supplied with your Icecast installation – probably in /usr/share/icecast/. If you installed from source they can be found in the source directory. I copied admin/, conf/, log/ and web/ to ~/.icecast/. Next was tailoring the Icecast configuration to my needs. The important options are:

• clients – This sets the upper limit on the number of clients which can connect, including the source client. This should take into account your available upload bandwidth and the bitrate of your stream.
• authentication – You should select strong passwords for all the accounts you can log into – we’re talking root password material here. It might also be a good idea to change the actual account names.
• hostname – If you have a dyndns domain or similar pointing to your server put it here
• listen-socket port – Something open
• paths – Set these to the directories created in ~/.icecast/

Now you can launch the Icecast server with:

$ icecast -c ~/.icecast/conf/icecast.xml &

You can check the error log – if your configuration is sound you should see a line like:

[2006-01-23 13:38:10] INFO main/main Icecast 2.3.1 server started

Ices

For the Ices files I created a directory off my home directory called .ices/. This contains the configuration and log files. You can find a sample configuration file in /usr/share/ices or the Ices source directory – ices-alsa.xml is suitable for most setups. The things you’ll need to change are:

• logpath – The .ices directory you created is the best place for this.
• pidfile – Set this to ~/.ices/ices.pid – we’ll need it later
• metadata – It’s a good idea to change this to reflect the content of your stream.
• metadatafilename – set this to ~/.ices/ices-metadata
• instance – You’ll need to change the server settings to point at the machine you installed Icecast on. You might also like to change the encode quality, downmixing and resampling. I chose 44.1kHz, stereo, q0 ogg-vorbis. This gives a stream of about 64kbps.

Now you can run ices with:

$ ices .ices/ices-alsa.xml &

You’ll need to set a default capture source. I used aumix to set it to capture anything that’s played on the soundcard (see the red button)

You should be able to do this with alsamixer. I couldn’t do it with kmix. Recording everything on the soundcard gives you the opportunity to stream live from your soundcard’s line in – you could stream from a record deck or add a microphone.

amaroK

There’s a very simple reason I chose amaroK and that is the availability of a Python script called ices-metadata which plugs into amaroK and sends correct track metadata to Ices. Upon installation of this script in amaroK change the configuration to reflect the location of the Ices pid and metadata files we set above. Using this the correct track and artist names are supplied with your stream.

Notes

You don’t have to use the setup I described above, of course. There are alternative source clients you can use such as DarkIce, the Oddcast plugin or if your processing power is limited, IceGenerator which streams already encoded files. There are also other options for streaming audio servers, including SHOUTcast, the Darwin Streaming Server and VideoLAN.

You can also supply several streams to a single server – using Ices this involves adding instance entries to the configuration file. You could, for example, have a high bitrate stream for your LAN and a low bitrate stream for internet users.

Icecast has a web template to display information about the available streams. You can customise this to fit your needs – for example, I removed links to other pages (such as admin and the redundant status link) provided a link to my last.fm profile to act as a track history.

If you are concerned about security (and you should be!) you can run the Icecast server as a low privilege user in a chrooted environment.

If you have any comments, suggestions, whatever for this post feel free to leave a comment.