"Developer Release 1" of
the next generation of the
X Multimedia System
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
Lately, active development of XMMS has mostly stopped,
this can be attributed to the lack of active developers, and a
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,
"Beep media player", comment on XMMS:
The XMMS code we inherited is old and messy.
In more specific terms, it is poorly structured, poorly documented
and littered with duplications. It is difficult to modify or
extend one component of XMMS without breaking another.
We spent most of our time fixing problems that were introduced
after seemingly innocent modifications.
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.
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
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
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.
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
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.
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
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.
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.
are encouraged to take a look at it, and take a
plunge into the code to help make it the
For more information have a look at
the XMMS2 Wiki
and join #xmms2 on freenode.
to post comments)