April 26, 2006

Network your music with DAAP for Linux

Author: Nathan Willis

Apple's iTunes popularized the Digital Audio Access Protocol (DAAP) for simple networked music playlist sharing. Linux users can take advantage of it too. Linux users can choose from several easy-to-use DAAP servers for sharing music, and several DAAP-aware applications for listening to it -- as well as discover and tune in to other people's collections.

DAAP was developed at Apple as a simple extension of HTTP. A good repository of information about DAAP is available at opendaap.org. DAAP clients and servers discover each other through ZeroConf and exchange basic information about their capabilities over HTTP, using the MIME type application/x-dmap-tagged and speaking on TCP port 3689.

Usage is equally straightforward. Servers send a list of all available songs and playlists. When a client requests a song, the server streams it back. Clients can periodically check with the server for updates on the available content.

The iTunes implementation of DAAP imposes an arbitrary limit of five unique client connections during each 24-hour period. In its original implementation, iTunes could connect to DAAP servers anywhere on the Internet, but Apple crippled the application starting with the 4.x release, and iTunes will now make DAAP connections on the local subnet only. The limitation is not part of the protocol, and the leading theory behind the change is that pressure was put on Apple from the major record labels to limit the service.

At your service

But enough about Apple. Those of us running free operating systems have several DAAP servers to choose from. daapd, mt-daapd, and deleet daapd are the most widely used. Out of the three, mt-daapd is the simplest and seems to have the most active development community, so it is the one we will explore here.

To install it, see the quickstart instructions available at mt-daapd.org. Binaries are available for several Linux distributions, as well as some distro-specific installation guides.

Mt-daapd is dependent on libid3tag and gdbm for keeping track of the music, and requires a ZeroConf implementation such as Avahi for automatic service discovery. Startup configuration is done through /etc/mt-daapd.conf, and the sample file included with mt-daapd includes plenty of explanatory comments and should be enough to get you started. Specify in the file which directory contains the files mt-daapd will serve, and, if you like, set a password users will need in order to connect to the share.

The first time you run mt-daapd it will scan the shared music directory and index its contents, including file metadata such as the ID3 metadata in MP3s. Mt-daapd ships with metadata support for MP3, Vorbis, FLAC, and Apple's AAC, M4A, M4P, and M4B audiobook files. Note that mt-daapd will stream Apple's encrypted files, but those files will play only on computers that are authorized to play them.

Inside /etc/mt-daapd.conf you must specify an administrative password, with which you can access the server's built-in Web administration interface (remember, DAAP is built on top of HTTP) via http://localhost:3689. At this URI you can start and stop the server, rescan the shared music, and alter other configuration details.

When the server is up and running, DAAP-aware client applications can connect to it and browse the entire music collection and any server-side "smart playlists" you create. These playlists are automatically populated according to one or more rules defined in the file /etc/mt-daapd.playlist using a simple syntax documented within the file itself. The example playlists include "Recently Added," which includes all files added within the past 14 days, and "'60s Music," which includes all files with a Date tag in the 1960s. The mt-daapd.playlist file is fairly well commented, and includes a number of usage examples to help get you started.

The mt-daap project wiki has some advanced tutorials for getting more out of your server, including adding remote MP3 streams to the shared music collection, tunneling the connection over SSH, and transcoding audio on the fly to raw WAV output. This is useful if you need to connect with a client that does not support every codec; for instance, in my experience, iTunes for the Mac does not handle streaming Ogg Vorbis correctly, even though a Vorbis plug-in is available that works for local files.

The client is always right

But enough about Macs. Those of us running free operating systems have several DAAP-compliant audio players to choose from as well.

The simplest option is to use Rhythmbox. Charles Schmidt added support for DAAP to Rhythmbox as part of the 2005 Google Summer of Code. To use it, you need Rythymbox 0.9 or later, and GStreamer 0.10 (on which Rhythmbox depends). The newer versions of Rhythmbox and GStreamer have not yet made it into all distributions, so you may have to build it from source. If you do compile from source, be sure to pass the --with-daap flag to the ./configure command.

The Mono-based audio player Banshee also advertises DAAP support, but I was unable to get it to work on my AMD64 system. Several other apps cite DAAP as being in the works, including (intriguingly) MythTV and a variety of KDE players that depend on adding DAAP underpinnings to KDE itself. And, of course, the Windows version iTunes is known to run well under WINE.

Several Java-based audio players also support DAAP; the mt-daap and OpenDAAP sites recommend ourTunes, iLeech, and GetItTogether. Most of these seem to predate the DAAP efforts of the Linux-native players. Here again I had limited success on my AMD64 machine. The temptation for me as a writer is to launch into a tirade about the "write once, run anywhere" mantra bandied about by both the Java and Mono communities, and how it is essentially fiction unless you use a stock system on i386 hardware with the exact same JVM/.Net runtime as the developers used when building their app. Instead, I will just caution you that -- as with a lot of Java apps lacking large development teams -- success may depend on your patience and your willingness to tweak your Java installation.

DAAP versus the file server

Luckily, as DAAP support breaks into the mainstream, specialized solutions like these Java players will become less and less important. We will ultimately see DAAP support shipping in the preferred GNOME and KDE music apps. In another year, expect it to be as ubiquitous as Internet radio streaming is today.

That is unquestionably a good thing. The more music you have, and the more computers you use, the bigger the hassle it becomes to try to synchronize everything. Without a simple sharing solution like DAAP, the easiest way to manage a centralized music collection for multiple PCs is keep all the files together on a central server, shared through Samba or NFS. DAAP accomplishes the same goal with far less administrative overhead, and provides interesting features like smart playlists at no extra cost.