Requirements for Advanced Linux Music System ============================================ Usecases: -------- Switch UI theme for Start ALMS in backtround at start of system Select song to play Stop, Pause, Restart song Switch to repeat mode Want to see song interpret, title, filename, id3-tags, remaining play time, total play time change relative loudness of song and directory change liklyness to be played for song and directory edit id3 tags add id3 tags (album,...) for whole directory sort directory by id3 song number save meta-information and title order in file UI for playlist server UI could be different for different servers. Maybe we need a generic protocol (PCP Playlist command protocol) - list (all?) files - next, previous song - get whole list - get current (selected) song filename - select specific song Easy to extend Programming language must be object oriented or script, e.g. Perl, Python, C++, java maybe to slow, to much overhead . Requirements: ------------ 1) Possibility to start alms in background. All needed parts must run in console Important parts may be demons This means playlist management and so on. 2) Should support multiple audio formats (mp3, mod, wav) possible to interface with different players 3) Should support themes Console UI would be good (see cams) Pluggable UI (because of easy to extend) send's commands via console program ??? send commands via tcp/ip (need new protocol?) ??? password for authentification needed allow multiple ui's - Start, Stop, Pause, skip - set volume - Reply with current song-name, current time - UI for playlist server (see below) 4) Possibility to switch between different playlist-modes Pluggable playlist server possibility to switch playlist server while playing?? 5) requirements for special playlist server Possibility to define a song-program depending on style of music database should contain beats, style (melodic, strange, ...), interpret database of song-infos because id3 tags are not sufficient (what about id3-2 tags?) seems like in fact id3v2 tags are sufficient Song program is the real word. Syntax should be programming language like. (perl eval?) 6) Possibility to advance song likliness to be played advance for whole directory 7) Possibility to raise/lower song volume raise/lower for whole directory 8) from 2), 3), 4) player, playlist and ui must be different programs (playlist and ui could be switched) 8.1) player can buffer a list of songs (songlist), so that playlist could be switched without problems 9) actions for player are: play, stop, pause, skip(seconds), volume, intro getHistory, getSonglist, getCurrent, add, delete 9.1) players songlist is unordered. because of 8.1) songlist is a shared resource. ordering could confuse playlists 10) actions for playlist are: next (received from player and ui) should route other commands through Example for simple playlist is "linear playlist", "random playlist". 11) To display current state of song, player has to transmit time information. Maybe we should transmit them on a different channel. first guess for modules player/s Audio::Daemon + xmms | | | | player/songlist interface | command | | | | | UI/s tcp/ip | | | | | | info | | | +-------tcp/ip--- playlist server/s | subclass of Audio::Daemon | | | | | | | | | | playlist | UI/s database (not needed because of id3v2) Benefits and shortcommings of existing projects =============================================== mpg321 _____ seems to be good. Small problem: starting it remote needs dummy argument. (ignore) Error output of Audio::Play::MPG123 could be better. Does not support remote gain and equalizer settings (patch for gain sended) cams ____ pro: lightweigth, graphic and console con: no modularity hard to expand (c) no extended playlist management MP3Daemon _________ pro: ligthweight console daemon easy to expand perl con: no graphical frontend extended playlist management rudementary module structure not good no back channel for play state. Have to poll for mp3 time and so on. Audio::Daemon _____________ pro: lightweight console daemon easy to expand perl multiple backends like xmms (big pro) con: no back channel for play state. Have to poll for mp3 time and so on. (intelligent poll possible with time information!) ampd ____ pro: lightweight graphical frontend (Tk ugh) console perl con: extended playlist management rudementary rplay _____ pro: console easy to expand daemon works over tcp/ip evolved con: no playlist management seems to have no possibility to get current song position seems to have no possibility to skip Curses::UI __________ pro: allows mouse lean good connection to developer con: hard to extend (for now) PerlGtk _______ pro: full functional good documentation con: heavy Problems with MP3::Daemon ------------------------- no fixed port number thus maybe problems for firewalls security problems not evaluated MP3::Daemon::Client should not be defined in Daemon. This is no function of the daemon but of the client (and does not return a client but a socket). sketch for playlist interface _____________________________ isStrange = (song->genre == "funk" or song->genre == "sound" or song->genre == "classik") myor mynot( song->like-factor > 50 ) songProb = calcSongProb( Definitions ___________ songlist: list of songs playlist: order in which to play songs playlist server: server that defines a playlist (possible on the fly)