Solaris@Home Part 4: Streaming Music
By user13366078 on Jan 22, 2006
Welcome to a new part in the Solaris@Home series. Since I dumped my old Qube and other stuff for a W1100z running OpenSolaris, we saw how to be more eco-responsible and enjoyed a ZFS-based DVB-T PVR. Now it's time for some music!
Meet AAC, the successor to MP3
Like many people, I love the simplicity and elegance of iTunes. All of my CDs are in my iTunes library, most of them as 128 kBit/s AAC and all newer ones as 256 kBit/s AAC. Disk space is becoming cheap enough, finally.
Some people think that AAC is proprietary to Apple, because they promote it so much. This is nonsense, AAC is an official part of the ISO/IEC MPEG4 open standard. Other people think that AAC brings the evils of DRM. This is double nonsense: First, AAC does not include DRM per se. Apple's Fairplay DRM system is a proprietary extension of the AAC format. You're still free to use AAC without any DRM, even when using iTunes (and not buying music from the iTunes store). And second, DRMs aren't more or less evil than simple padlocks are: They just provide a mechanism to restrict the usage of media to a certain group of people.
In terms of quality and positioning, AAC is the official successor to MP3. It offers better audio quality for the same given bitrate, or less space requirements for a given audio quality level. Of course, much of the perceived quality of an audio format depends on the implementation. Some public tests seem to confirm that Apple's AAC implementation is pretty good, even though it only used CBR at the time these particular tests were done. Meanwhile, Apple's AAC implementation also supports VBR, which should provide even better quality. AAC is widely available both in hardware and in software, so practicality is a given here as well, plus it's an open standard and we at Sun like open standards a lot.
One of my favorite gadgets at home is my Roku Soundbridge M1000. It understands a number of audio streaming protocols, including iTunes' proprietary DAAP protocol. So you can hook up this nice-looking baby to your stereo and your net, start iTunes and listen right away. And it comes with a digital output for your audio system too!
But I like to listen to my music even when my laptop is not currently powered on. That's where my trusty W1100z "Condorito" running Solaris Nevada is coming in. Thanks to Ron Pedde, there's an open source project called mt-daapd, an implementation of a DAAP daemon that can stream music from your disk to your devices at home, as if they were coming from an iTunes shared library.
As easy as 1-2-3
Serving music to your network on Solaris in an iTunes compatible way can be done in these 3 easy (for geek standards) steps:
Copy your music to a directory accessible from your Solaris machine. The easiest way is just to copy your iTunes folder with all the music subdirectories and the
iTunes Libraryfile as well. This file stores iTunes' playlists which mt-daapd can handle for extra comfort.
Compile and install some libraries, an mDNS responder deamon and mt-daapd itself.
Configure and install the mDNS responder daemon and mt-daapd and you're done.
Compiling and installing mt-daapd and friends
Before we install mt-daapd, a few prerequisites are needed:
DAAP is a service that relies on Zeroconf's Multicast DNS protcol in order to announce itself to the network. In other words: Without mDNS your music players wouldn't know that there's a DAAP server with lots of music sitting right there in your network. While mt-daap comes with a built-in mDNS responder, it's not very stable. Therefore, I prefer to install an independent mDNS responder daemon called "Howl". Howl compiles and installs fine out of the box. It now lives on my system in the
mt-daapd will scan our music collection and store metadata in a database. The current nightly build of mt-daapd uses sqlite3 as a database engine (the previous version sqlite 2 is also supported). Again, I just installed the sqlite3 package from Blastwave, but feel free to compile it on your own.
The mt-daapd website offers a stable version as well as nightly development builds. Of course, all the nice new features are only available in the nightly build, which in turn is sometimes buggy. Not being sissies, we're going to compile the latest nightly, which currently is the 20060117 version.
Since Rons development environment is kinda Linux-centric, he uses a function called
src/scan-xml.c. This function is non-standard, but a GNU extension to the usual set of timing functions, we learn from this manpage, which is ironically hosted by Apple. Since Solaris doesn't come with the
timegm function out-of-the-box, we need to patch
src/scan-xml.c and insert the piece of code that the above manpage suggests.
Now we're ready to configure the mt-daapd makefiles on our system. The following options to
configure worked for me:
./configure LDFLAGS="-L/opt/local/lib -L/opt/csw/lib" CPPFLAGS="-I/opt/local/include -I/opt/csw/include" --prefix=/opt/local --enable-sqlite3 --disable-mdns --enable-howl --with-howl-includes=/opt/local/include/howl --with-id3tag=/opt/csw
Note that I like to have self-compiled software installed in
/opt/local. Just change the
--prefix part if you want to install your mt-daapd elsewhere.
To build and install mt-daapd, I prefer to "
make" as a regular user, then "
make install", again as a regular user just to check what it'll do, then "
make install" as root to get it installed into the right place.
Configuring the mDNS responder deamon and mt-daapd
The following line in
/etc/mDNSResponder.conf will announce our DAAP server to the network:
# name type domain port text record "Condorito's Music" _daap._tcp local. 3689
After tweaking this config file, we just need to start the
mDNSResponder binary from the Howl installation.
Now we need to configure mt-daapd. The
contrib directory contains a commented sample
mt-daapd.conf file. Edit it to tell it where your music is stored and to configure some other settings. Since the sqlite3 support is quite new, it still misses the two new parameters introduced in the 20060112 build. So we need to add the following to our
# # db_type (required) # # Choose between sqlite and sqlite3 # db_type sqlite3 # # db_parms # # The directory to dump the database in # db_parms /var/cache/mt-daapd
As you see, we're going to let mt-daapd store it's database in
/var/cache/mt-daapd, so we need to create this directory and make sure it has the right permissions. In my case, I created a new user "daapd" to run the server as. This needs to be reflected by the
runas directive in the configuration file and we need to make sure that this user can create files in the
Finally, we can start mt-daapd and let it do its work by simply saying
/opt/local/sbin/mt-daapd. Watch the logfile at
/var/log/mt-daapd.log or whatever you specified in your config file. If something goes wrong (typically a permission problem or similar), then you'll find error messages there.
It's alive, Igor...
With mDNSResponder and mt-daapd up and running, you should now be able to see the server in you iTunes "Source" column under the name you specified in the
mDNSResponder.conf file. If not, something went wrong with the Howl mDNSResponder deamon. If you see your new DAAP service, you should be able to click on it and see the music shared through mt-daapd. Of course, this also works with any device on your network capable of the DAAP protocol such as my Roku Soundbridge.
I hope this little tutorial was useful to you and I hope it helped some of you get your music service up and running on Solaris. Next time, we're going to brush it up a little by properly introducing the mDNSResponder and mt-daapd services to the Solaris Service Management Facility (SMF).