Software:XMMS2

Short description: Free audio player

XMMS2

Developer(s)	XMMS Team
Written in	C
Operating system	Unix-like
Type	Audio player
License	LGPL-2.1-or-later
Website	www.xmms2.org

XMMS2 (X-platform Music Multiplexing System 2) is a new generation of the XMMS audio player. It is a new design, written from scratch, separate from the XMMS codebase. While Peter Alm, one of the original authors of XMMS, was responsible for the initial design and coding of XMMS2 (late 2002 to early 2003), he has since passed on the responsibility of furthering the project to Tobias Rundström and Anders Gustafsson. LXMusic, the default music player application in LXDE, is an XMMS2 client.

Design concepts

XMMS2 borrows concepts from XMMS-era music players, such as playback control, a playlist, plugins, user-configurable GUI, and adds features such as a media library and a client–server design.

Like XMMS, XMMS2 has a plugin architecture; a type of modular architecture where certain functions are delegated to loadable libraries which provide particular functions at run-time. XMMS recognised five different types of plugins:

• Input plugins for reading and decoding files or streams.
• Output plugins to handle sound output.
• Effects plugins to add effects to decoded audio data, before being output.
• Visualisation plugins to provide visual animations that vary according to the audio being played.
• General plugins which allow for miscellaneous functions such as controlling XMMS via an Infrared remote control or a Joystick.

XMMS2 also recognises five types of plugins, but they perform rather different functions:

• Transport plugins for reading files or streams.
• Decoder plugins for decoding data read by transport plugins.
• Effect plugins to add effects to decoded audio data, before being output.
• Output plugins to handle sound output.
• Playlist plugins to handle the importing and exporting of playlist data.

Unlike XMMS2, XMMS had no library where it stored information about a user's media collection. The only media resources XMMS knew about were its playlist. Starting in around 2000, players like Winamp and SoundJam MP began implementing simple database features that allow the player to "remember" where a user's media is located, as well as caching metadata stored in the files such as artist, title, date added and play count.

XMMS2's media library is well integrated with the playlist. This integration means that every file or stream added to the playlist has its metadata automatically cached by the media library. This only happens once for every unique URL, so metadata isn't read again if it already exists in the library. Besides metadata, the media library can also quickly and efficiently store and reload playlists, making a user's music collection all accessible from a single place.

One feature of XMMS2 that has been rarely implemented in media players is its client-server architecture. XMMS2 allows the user to choose from a number of interface implementations for searching, selecting and playing media, then to close the interface while the audio plays "in the background". The interface can be reopened at any time for further use. Other players with similar features on *nix include the Music Player Daemon and Music on Console.

The design

When first conceived, XMMS2 was simply a shared library. That is, XMMS2 would be back end code to take care of the mechanics of decoding and playing audio streams, requiring to be linked into a compiled program that provided a user interface. This concept was later expanded into a client–server model to allow for more flexible coupling between the front-end and the back-end. The advantages of this approach are:

• This allows any compatible client(s) to connect to and control a single instance of the XMMS2 daemon.
  • Clients can offer various types of user interfaces – graphical or text based, implemented using various toolkits, integrated with various desktop environments.
  • Client developers can concentrate on improving the usability of their interface, and not worry about playback code.
• The use of TCP sockets also allows for users to remotely control XMMS2 daemons over a TCP/IP network.

While the plugin architecture of XMMS allowed it to be quite extensible, it was inefficient in certain ways; XMMS2 seeks to improve on that.

• XMMS has Input plugins that take care of reading data and decoding it to audio. XMMS2 splits this into a Transport stage and a Decode stage, so that a single transport plugin may supply data of any type to any decoder plugin (such as an HTTP plugin reading mp3 data from a web site).
• General plugins may prove to be less relevant in XMMS2, as their purpose may be served by standalone clients, but the plugin architecture will still exist.
• XMMS can't handle container formats in a general manner. The XMMS2 architecture makes it easier to build support for container formats.

XMMS2 and other projects

The name "XMMS2" was chosen by Peter Alm and Tobias Rundström as they started work on the project, evidently intending it to become the successor to XMMS. However, other developers started using the name (in 2003) before Peter and Tobias ever released their code:

• Another project named XMMS2, was described as "a Gtk 2 port of the well known xmms." This was not related to the project discussed in the rest of this article. The project has now been discontinued and removed from GNU Savannah.
• A better known GTK+ 2 port of XMMS is the Beep Media Player, which is sometimes referred to (erroneously) as XMMS2. The BMP FAQ explains that project's relationship to XMMS.

A subtle difference between the XMMS and XMMS2 acronyms is that, while XMMS stands for X (originally for X11 then Cross-platform) MultiMedia System, XMMS2 stands for X(Cross-platform) music multiplexing system. This decision was made to make it clear that XMMS2 would only ever be an audio player, and not a general multimedia player with video support.

External links

• XMMS2 homepage