+---------------------------------------------+ | | | MPSERV : A Distributed MP3 Playing System | | | +---------------------------------------------+ Hi, this is a pre-release version of a distributed MP3 playing system. Basically, you and your friends have MP3s all over your hard drives, you each run a program that collects the locations of all your mp3 files and puts symlinks to them in a web-accessible directory. Each host provides an index of the mp3's that it contains and how to get to them. What this means is that it doesen't matter where in particular your mp3's are kept. You can keep them all in a single directory, or scattered across a bunch of different partitions. This information is collected by a sever running on some machine which can produce sound. The server has a list of hosts to query for mp3's, and it compiles this into one big list. The server listens on a port and can be controlled by either talking to it directly or through a client. At present there is just a perl/gtk client available, although it should be possible to write the client in any language you wish as long as it is possible to open a socket and talk to the server. The mp3's are played by streaming them to mpg123 via http. This means that you'll need to be running a web server on each host that has mp3's stored on it. If privacy is a concern, it is easy to get apache to accept connections to the mp3 directory from a select number of hosts. Then you won't get in trouble for vicously slitting the collective throats of the music industry and running off with their precious intellectual properties. We have also included a ripper so you can copy all your music into mp3 format (with proper naming). Then you can have all that music in the oh-so-cool ON DEMAND format. One advantage of this architecture is that there is no arbitrary limit on the number of participants involved. You can have mp3's strewen across as many machines as you like. The advantages of This are many. You can create a common pool of music accessable from any machine. The number of servers running concurrently is also not limited. So for every room that you want music in, all you need is some computer with a sterio, and you have instant access to all your music Likewise, you can have more than one client talking to the same server concurrently, so more than one person can control what music is playing, on any of the servers. There is currently not any kind of authentication mechanisms in place on the server. Note: This system may not work if your network card is garbage. An easy way to tell this is to test the throughput you get when ftping files between two machines. Most mp3's require 128 kb/s throughput (16 kB/s). Believe it or not our cards were so cheap at first that they were not able to maintain that kind of throughput. +------------------------+ | | | Software Components: | | | +------------------------+ The Server ---------- need: mpg123 >=0.59n, perl >=5.002 usage: perl server.pl desc: Attaches itself to port 2600 using the TCP protocol. There is a (purposely) rudimentary CLI available. Just telnet into the server and type 'help' for the commandset available. This is truly meant to be used by an external (probably GUI) client. The server holds a database of all mp3's available as well as a playing queue holding the song currently playing and any waiting to be played. A basic set of operations are supported, including addition, promotion, demotion and deletion of queue elements. If the currently playing song is deleted, it will stop playing and the next song in the queue will begin. If it is demoted, it is interrupted and the next song in line is played. The first song is then requeued to be played next. This is equivalent to promoting the number 2 song in the queue. The Client ---------- need: perl >=5.002, GTK >= 1.06, Perl/GTK >=0.5000 usage: perl client.pl [host-address] desc: A GTK client for playing and modifying the server mp3 queue. Omitting the host-address causes the client to look at the localhost for the mp3 server. The GUI client should be fairly intuitive. The top frame contains the tree of available songs broken down as Artist => Album => Song. The frame below contains the list of songs that are currently in the server's queue. A bunch of buttons occupies the bottom of GUI, they control the song position in the queue, deletion, queue refreshing and tree refreshing. The playing queue is automatically updated whenever a change is made by that particular client. Changes made by other clients are not visible until the refresh button is pushed. This includes when songs have finished, as queue traversal is left up to the server. To fix this a server push mechanism is needed, where each client registers as a 'listener' and is notified through a server of its own when changes have been made. This has yet to be implemented. The MP3 locator --------------- need: perl, gnu locate usage: perl mp3_locate.pl desc: sets up the mp3 servers The mp3 locator locates all of the mp3's stored in a system by parsing the output of a `locate *.mp3`. A configuration file is read that says where the web directory is on each machine. For every mp3 on the machine a symlink is created from the /mp3 web directory to the file, and a line is added to the index file containing the name of the mp3 and a url that can be used to get it. The server then queries each machine with mp3's by doing a GET /mp3/index to build a list of all mp3's available. In the configuration file you can specify a directory that will always be checked for mp3's so you don't have to run updatedb everytime you download new music. You can also specify directories to never check for mp3's. The Ripper ---------- need: cda (comes w/xmcd) bladeenc (or edit the script to use another encoder) mp3info (if you want to write ID3 tags) usage: perl ripenc.pl desc: CD to MP3 (rip and ecode)er Pop the CD into your ultra-high-speed CD-ROM and it will be looked up in the CDDB. You'll be asked for the album release year. Then the whole CD is ripped to disk and then BladeEnc takes over, converting it to mp3s. If you want, an ID3 tag will be written with the genre you specify. +--------+ | | | TODO | | | +--------+ * server pushes This involves the client listening on a socket and registering itself with the server to recieve updates of playing queue, tree, etc. This is necessary for the playing queue to update when songs are done playing. When I want to know what song is playing (i.e. I don't know the song) I find myself hitting the refresh q button all the time. This would fix this. It would also let changes from other people become immediately visible. * server logging (history) This could be useful both in terms of 'what was that last song?' and in gathering statistics of the most played songs, etc. We could then have nifty things such as personal/global top 10 lists (or top n list if you prefer) * Music Tree The music tree is the tree that at present contains only one top level node, mp3's sorted by artist/album/song. I would like to generalize this so that you can drag any node off the tree to either a playlist (see below) or to the playing queue. This would make it really easy to play entire albums/etc. It also makes more sense when more top level nodes are added to the tree. Future top level nodes could be one for playlists, and one for statistic related stuff/server history. * playlists (drool) I'm thinking of implementing playlists as follows: A playlist is a list of playable objects. Playable objects can be individual songs, albums, entire artists' work, a top ten list, or another playlist. The playlist is represented hierarchically as a node under the top-level playlist node in the music tree. When creating a playlist, the user can either drag nodes off the music tree directly into a playlist, or grab songs from either the playing queue or the server history. * java client (for those nasty os'es that don't have gtk) There's no reason that the gtk client needs to be the only one. It's just more fun than java :) * user configurable web dir (not just /mp3) * verify symlinks being made by mp3_locate * server timeouts This software is being written by Jeremy Avnet and Brian Martin. Contacts: brian@theory.org && jeremy at theory_org