It seemed like a simple question. Consider the problem of [a], a collection of ripped music from a large CD collection, [b] a server containing said mp3’s, located on a bookshelf in the corner, [c] a very nice Bose Lifestyle 48 audio system, and [d] a couch potato like myself wanting to listen to that music, but not willing to walk over to the workstation, hook up a monitor (it’s normally headless), and play something.
There were several things I wanted under the general heading of “I want to listen to music stored on that machine,” but no clear path in sight.
So how to approach this problem?
I’d been considering certain options with respect to making those mp3’s available to listen to. I’d already mounted the exported filesystems from ‘yawl‘ (yes, my old desktop machine is now my music server) to make it possible to sync some of the music to my iPhone via iTunes. That also made the filesystems available to Cat and our roommate, but wasn’t a perfect solution. Indexing and searching weren’t possible, etc etc.
The next choice was to let iTunes on the local desktop have access to the library, and do it’s own indexing. While this ‘worked’, there were a number of problems. Indexing a large library was PAINFULLY slow (an hour or two of machine-grinding, no-feedback processing before the library was available), coupled with the absolutely abysmal implementation of iTunes under Windows (Hey Apple, when iTunes is busy doing something? Let the user know!). Oh, and one other thing? iTunes has no capacity for rescanning a library for new content. I can’t say ‘there is my library, I’ll toss mp3’s in there regularly, rescan to see my new tracks.’ – So, no iTunes
Along this time I really sat back and thought about what I was looking to do. What did I want out of this? I came up with a list of capabilities I wanted…
- Manageable Storage
The storage systems for the music had to be manageable by tools other than the music tool itself. This means a real filesystem on a real server. I would prefer that machine to be Linux, but it was not absolutely required. I did not want to have to ‘import’ all the music into some black hole of storage. Filesystems are there for a reason. Use them.
- Remotely Maintainable
This sort of goes with the above requirement. The machine and system that hosts the music needed to be able to live “somewhere else”. That much disk space and hardware wasn’t going to stay on my desk, and whirring fans need to be away from my living / work space.
- Free or very low cost
I don’t have much of a budget. Using existing hardware was a requirement, and forking over cash for extra software is not in the cards.
- Not requiring specialized or custom software
There’s a number of music servers out there that are commercially licensed, but only make the media available via a specialized client. Invariably, that client is Windows or Mac only. No thanks.
- Play music locally
I needed to be able to remotely tell the server to start playing music – queue up a series of tracks, and play them through the sound card in the server. This way I could wire up the machine to the stereo and say “play”.
- Stream music remotely
Supporting streaming music to remote devices / desktops / computers is a must. I won’t always be in the same room as the server. Doing this without having to mount the filesystem is sort of the whole point of this exercise.
- Control via web client
Ultimately, I’d like to be able to control the music server and it’s audio streams via a web browser. The idea of using Safari on my iPhone to update / change the active playlists just makes my geekbits burble with happiness.
The first thing I considered was using an iTunes music server, but given my experience with iTunes thus far, I wasn’t particularly enamored of the whole Apple approach to things (“We do it this way, and that’s how we do it. Don’t like it, tough. Maybe we’ll change it later.”)
I’d heard of other folks using linux servers for audio management, so off to Google I go. It didn’t take long to find MPD – the Linux Music Player Daemon. In many ways, this is exactly what I was looking for. MPD sets itself up as a running server on a machine. You give it a location where music is stored, a couple simple parameters, and say “go”. On startup, it indexes your music directory, and goes into “Right. Ready.” mode.
I installed Sonata onto ‘algol’, my Linux laptop, and told it where the MPD server was. After wiring up a patch cable from the sound board on ‘yawl’ to the Bose Lifestyle, I used Sonata to search for a few tracks, and put them in the queue. Lo, music started playing! I was set.
MPD has a lot going for it. It’s simple, lightweight, and runs in the “I am a server, use a client to work with me” mode, which I respect. There are dozens of clients for it, from command line to windows to mac to Linux and beyond. Score!
Now, there are some issues. (You knew there had to be a gripe in there somewhere). I haven’t set up the audio streaming via Icecast yet, but that’s next. I did have one problem with MPD, and that was it had a hard time with a very large pile of music. I asked it to index my entire MP3 collection on startup, totalling about 300gig, and after an initial scan (took a few minutes), it… stopped. ‘top’ showed it chewing up an enormous amount of memory, and ‘yawl’ was thrashing away swapping. Something was amiss.
The workaround was to change MPD’s home music directory to a space that had symlinks in it. I linked in pieces of my music collection so that we were down to only 60 gig or so addressed via the symlinks. MPD came up almost immediately with that configuration. I’m going to continue adding in directories (since I believe the initial cache is now built), and see if I can cause this to happen again. But for now, it’s working!
The next step will be to set up Icecast for streaming to remote devices, and then installing a web interface (there are apparently several that are optimized for iPhone safari usage). Stay tuned!
12/23/2008: See a followup post regarding Icecast and further MPD configuration details.