Introducing the XMMS2 Media Player

"Developer Release 1" of XMMS2, the next generation of the X Multimedia System (XMMS), has been released. This article describes what is new in XMMS2.

Why bother working on a next generation XMMS while there are various existing and possibly more advanced projects already in progress, some which are ready for production use? Because XMMS is just too damn popular to be allowed to die, of course! But seriously, while the field of 'audio playback' in general is something of an old beaten path, there is still much room for improvement.

Constant progress is happening in the field of digital audio playback, including: new compression/encoding schemes, better and more flexible encapsulation and container formats, more efficient encoders and decoders, better ways of managing collections of music files, new ways of letting users interact with their music and so on. XMMS2 jumps into the mix with the goal of trying to provide an improved music listening experience for users.

The XMMS2 project started in late 2002 as an idea to make a "kick-ass music player", and has eventually evolved into the next generation XMMS. The need for an XMMS replacement had been evident for years: the XMMS codebase and framework weren't exactly well-designed from the beginning. Lately, active development of XMMS has mostly stopped, this can be attributed to the lack of active developers, and a broken codebase. Adding new features to XMMS is difficult. Some of the most-wanted features would be nearly impossible to add. Some parts of XMMS are beyond patching, a re-design of the framework is needed.

Developers of another fork of XMMS, BMP, the "Beep media player", comment on XMMS:

The XMMS2 team is committed to producing a better music player, while diligently maintaining a robust and flexible design. The goal is to make the system easy for developers to maintain and integrate with. In terms of the listening experience, XMMS2 makes it possible for anyone to easily manage their music collection and to interact with it in a flexible manner.

A Client/Server Model

XMMS2 runs the core player and user interface(s) as separate processes. The core player acts as a server to which user interfaces can connect. The interprocess communication is carried out over a Unix socket or a tcp connection, but all of the details are hidden from the client in a high-level client library.

The library also has bindings for Python and Ruby, simplifying the creation of clients. Putting the user interface in a separate process provides the opportunity to offer some very nice features. It allows any number of clients (user interfaces) to be connected simultaneously.

When you are sitting on your sofa with your laptop, you can just ssh to your desktop where XMMS2 is playing, and use the text interface to change songs, much like using xmms-shell for XMMS, but XMMS2 is designed for this from the ground up, and all clients are first-class citizens having full access to all of the available features.

Support for multiple clients also means that you don't have to keep a client connected - you may start the player, load a nice playlist and start playing it, and disconnect your client without killing the core player. This flexibility makes XMMS2 well suited for a headless system, and allows it to be controlled from a web browser.

The client-server model allows XMMS2 to be completely desktop environment agnostic. It is possible for one user to run the core player with a client that integrates tightly with a KDE-desktop, while another user runs it a with client that just sits in his/her Gnome panel. At the moment, there are no finished and stable GUI clients, but the plan is to write a small skinnable client that isn't bound to either KDE or Gnome. This will be shipped with XMMS2 as the default GUI client. The XMMS2 team also hopes that third-party clients which are more tightly integrated with individual desktop environments will be independently developed.

If you are familiar with XMMS, you know that its plugin system allows plugins of type "General", which are used to provide functions such as controlling the player using an IR remote control (xmms-lirc), running specific commands when a new song is played (song_change) and starting playback at a specific time (xmms-alarm). In XMMS2 all of these functions can be implemented as special clients.

This increases the stability of the core player, as the core player will continue to work fine even if one of the clients crashes. This design also speeds the development of such functions up in two ways, the client doesn't need to be unloaded and loaded from the server to test each change, and the server will keep running even if the client has crashed.

More importantly, the client functions can be written in a scripting language such as Python or Ruby. Visualization works exactly the same way - a visualization client requests visualization data, and processes it to produce fancy real-time visual graphics. Currently, only frequency information is available, wave data will probably be added in next release.

The Medialib

Displaying just the filename or URL of an audio stream in the playlist isn't very attractive, metadata such as the artist's name and the song title should also be shown. This media information is generally available inside the file (or stream) itself, like the ID3 tag in an mp3 file, and must be parsed. This parsing takes some time, and if it had to be done every time a song was added to the playlist, it would take a noticeable amount of time to add an album to the playlist. To solve this problem, the media info is cached in a database, named the 'medialib'. When a song is added to the playlist, the medialib is first queried, if the song has been seen before, the media info will instantly be available and the operation of adding songs to the playlist will be much faster.

This also has a very nice side effect: all of the mediainfo from the songs seen by XMMS2 will be stored in a database. This makes it possible to perform queries to find songs that have certain properties. For example, finding all songs by a certain artist or of a particular genre. This is so useful that a command was added to import music metadata straight into the medialib. The medialib is implemented as a standard SQL database using SQLite.

The medialib can be queried using SQL, and the possibilities are only limited by one's imagination. Examples are: "list all unique artists", "all artists with more than one hour total playtime", "10 random songs from artists beginning with 'a'", "100 random songs which are longer than 2 minutes and have the genre 'electronic'", and "select one song from each year between 1980 and 2003".

If logging is enabled, which it is by default, an entry is written to a log-table in the database every time a song is played. By using this table, even more complex queries can be made: "10 random songs that weren't played last week", "20 hangover-songs (that have been played Saturdays 10:00-14:00)". The power of querying the medialib would be apparent when XMMS2 is coupled with a client that abstracts away the SQL queries in a simple, but effective manner. No such client exists today, but the potential is great.

Transport Plugins

One of the problems with XMMS is that each input plugin is responsible for reading data from files or streams. This means that every input plugin wanting to be able to load a file over HTTP must implement its own HTTP code.

In XMMS2 the "input" plugins are split into "transport" and "decoder". Thus, if an HTTP transport plugin is installed, all supported file types can be loaded over HTTP.

Summary

While it is far from being able to replace XMMS as the de-facto standard music player on linux desktops, "Developer Release 1" of XMMS2 shows that the potential is there. Hopefully, the development of interfaces will be accelerated now that a public release has been made. All developers are encouraged to take a look at it, and take a plunge into the code to help make it the music player.

For more information have a look at the XMMS2 Wiki and join #xmms2 on freenode.

Index entries for this article
GuestArticles	Waldenborg, Anders

---

to post comments