You are here

From XMMS to Audacious: the history of a Winamp clone

One of the most used functions on any modern computer is the ability to play back music. From the first beeps and bloops in arcade machines, to the AdLib and the first Sound Blasters in home PCs, to the monstrosity of the 51 million transistor Sound Blaster X-Fi, people have listened and continue to listen to music on computers.

Back in 1997, someone finally decided to write a usable music player for GNU/Linux: X11Amp, now known as XMMS.

Winamp, X11Amp, and XMMS

Way back in May of 1997, a little known software company named Nullsoft released a piece of software that instantly became a hit, and is now, today, one of the best known examples of a music player: Winamp.

Justin Frankel’s work, this music player is the de facto player on Windows. Also, similarly, Winamp suffers from a severe bug: it works on Windows only. So, Peter and Mikael Alm, a few months later in November, released a clone of Winamp and named it X11Amp. X11Amp was released as free software.

Peter and Mikael wrote this software because there was a “lack of good MP3 players for Linux”. Cloning the look and the features of Winamp, and allowing people to use the popular Winamp skin format, X11Amp quickly became just as popular on non-Windows platforms as Winamp had on Windows.

By 1999, our intrepid X11Amp developers had picked up a sponsor, 4Front Technologies, which are known for their work on the Open Sound System (OSS) (which has since been replaced with the Advanced Linux Sound Architecture (ALSA)). Through this sponsorship, the X11Amp soon became XMMS. This is around the time I started using XMMS, and started paying attention to XMMS development; thanks to a lot of internal politics issues, it was very... interesting to watch.

The end of XMMSangelion

Continuing on for 5 more years, XMMS gained plugins for almost every sound format on the planet, and spat out dozens of stable releases. Development has ceased as of early 2004. In those 5 years, people learned several things:

The first version of the GTK+ UI toolkit, although the first of its kind, and pretty much the only UI toolkit when XMMS was started, was buggy, missing features, ugly both inside and out, and a pain to develop for. GTK2, GTK+’s successor, was vastly improved.

GTK+ and GTK2 library symbols conflict, so even if the XMMS developers wanted to change to GTK2, all the old plugins for XMMS that still used GKT+ would crash XMMS if you tried to use them; this crash does happen in forks of XMMS that use GTK2 and remain compatible with XMMS’s plugin API (such as BMP).

XMMS passes the original memory references of XMMS structures to the plugins, which allows badly written plugins to crash XMMS in new and interesting ways.

There was no clear way to proceed without a lot of code rewriting, and XMMS was due for a rewrite anyways. That, and the code confused people similar to how a certain Hideaki Anno film did.

By 2002, Peter Alm started a fork of XMMS, named XMMS2, to continue on rewriting, adding new features, adding GTK2 support, and breaking the plugin API to both fix various small issues and to prevent people from using original XMMS plugins without proper porting first.

Peter also wanted to split plugins into “input” and “transport” categories (since a lot of input plugins had redundant code for internet streaming and other similar things), add media library functionality, and split the player engine away from the display (making them communicate through sockets). XMMS2 development seems to be active, yet they aren't making releases often. Unfortunately, I think the project will die out due to lack of frequent releases and publicity.

BMP and BMPx

Starting at around the same time as XMMS2, Beep Media Player (BMP) (lead by Milosz “deadchip” Derezynski) forked XMMS but (unlike XMMS2) intentionally kept the XMMS plugin API. In fact, as long as you don’t pop up “configure” or “about” dialogs for plugins, you can use already compiled plugins from XMMS with BMP with no other problems.

BMP development continued on until Milosz decided that XMMS/BMP really did need a major rewrite; although, from what I’ve seen, he hasn’t agreed with Peter on what XMMS’s replacement needed. In October of 2005, Milosz forked BMP (which was essentially XMMS with GTK2 and a ton of code refactoring, but not much in the way of new features) and called it BMPx; although I use the term 'fork' loosely, as he decided to start the rewrite from scratch. In addition, BMPx is designed around using Xine (and later GStreamer) as the plugin system.

Milosz did alienate several developers during BMPx development when he decided to scrap BMP's original code. Some left in anger, others left because they were board with the project, and some decided to work on some of the other media players.

However, in my opinion, BMPx seems to be a dead end.

Audacious

Leaving off where the BMP development team stopped, William “nenolod” Pitcock decided to fork BMP a few days after Milosz started BMPx, and called it Audacious. Starting as just a large bug hunt, Audacious seems to have inherited XMMS’s title as de facto music player for GNU/Linux.

William has so far fixed dozens of annoying bugs, added the ability for outside clients to connect to the music engine, has partially rewritten the MP3 decoder (which, in my opinion, now sounds better than libMAD, the previous best MP3 decoder I’ve heard), and he is now in the process of adding an API to allow Audacious to be used similar to how GStreamer is used.

Between Audacious and BMPx, Audacious seems to be the only project that is actually continuing where XMMS left off. BMP essentially was a huge maintenance and code refactoring effort, although useful, it did not add any really new features, XMMS2 died off, and BMPx is going nowhere.

So, if you’re still using XMMS or BMP, try Audacious. The worst thing that will happen is you’ll rediscover how easy it is to listen to music on GNU/Linux.

Probably worth mentioning in any article about XMMS, that according to the Collabnet software quality studies done a few months ago, XMMS had the lowest ratio of discovered bugs to total lines of code.

I'm not entirely sure that's a solid metric of code quality, but it's got to mean something, and kudos are due to the people who wrote XMMS, IMHO. ;-)

If I remember the stats correctly, the audit picked up 6 bugs in the XMMS software itself, and those were all corrected - meaning that now, XMMS is pretty much bug-free. Now, as mentioned in the article, a plugin can crash XMMS...
It doesn't really matter to me: I mainly listen to streaming Vorbis radio, and there XMMS works just fine (with a very nice Ayo skin ;).
---
A computer is like air conditioning: it becomes useless when you open windows.

Historically, projects that don't release and PR constantly die out. XMMS2 rarely releases, and is almost unheard of; if XMMS2 doesn't change this, then XMMS2 will, in fact, die out. Now, hopefully since I mentioned XMMS2 here, this won't happen, but good projects die all the time. Thats just the way it is.

The XMMS bug count fell to almost none to zero, but the code is so unmaintainable that we eventually decided stop working on it. You guys don't really get what software development (not "churning out code for the money", but i really mean software development) is about, and what decisions have to be done if you're a project manager, and are trying to think long term.

XMMS has zero bug count but the codebase is so flawed that no one who codes would want to put his fingers into it. I very much doubt the Audacious developers would have had any fun with it before we actually rewrote approx. 60-70% of the XMMS code; all they did was cherrypicking, taking the codebase after we had brought it to a minimal level of real maintainability (far from what i'd call maintainable but at least something that can be worked on), and the countless bugs we've introduced were just the result of taking apart a big block of spaghettized monlithic code which you really can not take apart without breaking everything of it at once in various spots.)

A business that has limited funds (as almost every business has; it's a result of their growth and a balance between funds/venture capital and the amount of products/product lines and/or their complexity/range and external investments) and has to get in some revenue constantly (same thing; or they just go, well, "out of" business), it has to always keep a working product line going, and can't allow for too much research on sideprojects or some "next-gen foundation", but development is inherently iterative due to the business constraints.

Or (or!) you have so much money that you can have something out there that works in the meantime, and in your back offices develop something that is experimental. With free OSS development (volunteer work, not paid by companies; that is, free software developed by people in their free time), the strain you have is comparable to a company that has a) nothing to loose and b) has unlimited funds. But, that isn't enough.

That's where many OSS projects fail in the way you've described, since they just slumber along (nothing to loose: nothing to do!).

*We* have a _long_ term goal, but it's not laid out into infinity. We are watching timeline constraints, but we're not stupid enough to haste things nor are we under cash pressure so we can leave the 1 or 2 years it takes for BMP 2.0 to come out.

You should take a look at: BMPx FAQ: Missing 'trivial' features

I'm sure some "senior" (whatever that means; I've met too many 60 to 70 year old junior seniors in disguise so far) "developers" or "consultants" or "experts in the IT field" will contradict what we're doing and call it doomed from the start (heh) but you're just ain't getting it.

Dip your fingers into the XMMS code and then we're talking. If all that matters to you is a zero bug count, and not maintainablity of code, then you don't know anything about economics, in the educational/scientific sense, as well as in a mere natural, instinctive sense, nor do you seem to get that the entire OSS development ecosystem is geared towards creating stable foundations rather than pushing out finished products at point releases.

Before you anchor your hook into the previous statement: That's also where a lot of projects fail; they keep creating infrastructure for so long that they seem to eventually forget they were actually planning to release a product. With BMPx and BMP2, we have something that is usable _right now_, yet it's still only the draft of BMP2. It's both at the same time: A clean codebase with very good maintainability, and at the same time already a usable media player. We put the 2 things of this hypothetical company that has unlimited funds into *one* box: the product that is out there and works, and the development project; and guess what, it works for us. Maybe some others have failed, but that was then their misguided management or no-grasp what management of software development (to extend on the previous term) is about.

It might take another year or one and a half until we have BMP 2.0 out but after then the amount of maintenance will be minimal, the codebase will be extensible, and the right foundation for BMP 3.0.

Actually the Audacious developers didn't have much fun until most, if not all of the newly introduced BMP code was rewritten. I would indeed agree that countless bugs have been introduced at this point, which are now resolved. Now that the foundation is solid, individual areas of the code are selected for a performance-enhancing rewrite, which at times adds more features as well.
In other words, Audacious does partial rewrites in-between releases, with the codebase never unusable for over 48 hours. Having absorbed most of the plugins allows us to keep even SVN in a workable state. I'm not sure that "that was wrong, I'll smash it all down and rewrite from scratch" is a good approach, especially if it happens more then once.
Generally, a good way to see which open source software is succeeding is how much developers it attracts and can keep interested. In your company analogy, how many employees one can retain. It would suffice to say that Audacious is a much larger company.

Thanks for bringing Audacious back to my attention. I tried it early this year and it was still quite immature and Beep Media Player was more stable for me. After your article I found that it had advanced quite a bit along with a package in Debian Unstable. I really like just a simple audio player in a lot of instances and I have a number skins I've grown fond of over the years.

I'd like to give a tip of the hat to the coders all along the way from X11amp to Audacious that have brought us this fine program.

For those who don't know who he is, Hideaki Anno is the main writer behind the Evangelion anime series at Gainax' studio (he co-founded it, as a writer first then as a director).
The series, interestingly enough, didn't end on a definite note (but a dark yet hopeful one), which confused most of its fans (having thought about it for a looong while, I found it ended very well on its own - it was overly hard on any eighteen year old's brain who hadn't taken philosophy as its main course, though).
In reaction, Anno decided to make a movie (the End of Evangelion) which some claim is the 'proper ending' while others describe it as an unnecessary slugfest. Its animation was flawless, the action contained one of the most violent fights seen to date in Anime, and it closed most of the plot holes in the series - it was thus technically perfect. However it litterally ended on a sick note.
---
A computer is like air conditioning: it becomes useless when you open windows.

Was that statement a reference to the stability of BMPx as an audio player or to the activeness of the releases? Because as far as I know BMPx runs quite well (atleast for me) and is very active in releases. Having used all kinds of media players including resource hogs like Rhythmbox and Amarok I believe BMPx is a great step forward. In that way I also think it to be a bit unfair to mention it in the same article as just simple media players like xmms and audacious.

> Starting at around the same time as XMMS2, Beep Media Player (BMP) (lead by Milosz “deadchip” Derezynski) forked XMMS

Wrong, I forked off XMMS earlier than XMMS2 started, at least as far public availability goes. (EDIT: In hindsight or as i remember now it was actually so that i was mailed by the XMMS guys when i first forked it and they asked me whether i wouldn't rather want to work with then on "XMMS2", but i have no idea how far the project had proceeded at that time, so it's probably valid to say "around the same time".)

> BMP development continued on until Milosz decided that XMMS/BMP really did need a
> major rewrite; although, from what I’ve seen, he hasn’t agreed with Peter on what
> XMMS’s replacement needed.

First of all this was not my, but a team decision. We didn't "ask Peter" since we don't have any obligations towards the XMMS/XMMS2 developers; there was nothing to agree _upon_, and especially with BMPx, since it was written from zero with only a minimal amount of original BMP code (not even really XMMS code anymore since it as refactored already for a long time).

You seem to think that just because (the first, initial, XMMS forked BMP) was a fork, we had some kind of obligation towards the XMMS developers or what is the point you're trying to make here?

>In October of 2005, Milosz forked BMP (which was essentially XMMS with GTK2 and a
>ton of code refactoring, but not much in the way of new features) and called it
>BMPx; although I use the term 'fork' loosely, as he decided to start the rewrite
>from scratch. In addition, BMPx is designed around using Xine (and later
>GStreamer) as the plugin system.

You're not using the term "loosely", you're entirely misusing it. I didn't fork it off, I've laid the foundation in a separate codebase and as soon as there was something the rest could work on with me, we started to work on it together. The "code refactoring" phase was much earlier, at times of the XMMS-forked (now in the right sense of "forked") BMP.

GStreamer is not exactly a plugin system either. I encourage you to tell the GST developers that it is one, but beware of being flamed and chased into the bowels of hell.

("[...] although I use the term 'fork' loosely, as he decided to start the rewrite from scratch" How about "I totally abuse the term and in fact he just wrote it from scratch but since i love using all those leet F/OSS words I'll just call it a spoon. Fork. Whatever.")

> Milosz did alienate several developers during BMPx development when he decided to
> scrap BMP's original code. Some left in anger, others left because they were
> board with the project, and some decided to work on some of the other media
> players.

Board. "Bored" perhaps?. Well AAMOF no developers left because of the rewrite which again was not the initial fork of XMMS (your text is really way jumbled up basically beyond correctability; maybe I should "fork" it and "rewrite it from scratch" instead...). There were no developers alienated because of our change. Some left later on but for other reasons than the code rewrite (like, becoming more active in infrastructure development e.g. GStreamer or Gtk+.)

No one from the original BMP team as far as I know works on other media players. (Sounds like you're trying to tell a goodnight story for children to sleep: "And if they didn't die, they still live somewhere out there, working on other media players!")

It looks to me like you've read our About page, did some kind of minimal research or something, and then intentionally jumbled this up. I'm not necessarily saying you did, but being a person who actually *lived* through all those times from X11amp to Audacious, and being the initiator of the BMP _project_ which currently develops BMP 2, I know the actual facts, and you've just got them so plain wrong that you either made it all up or deliberately forged them so your article can make a point on Audacious. You've simply got all facts surrounding BMP development wrong; all of it.

Also, you just fail to realize that BMPx is, while it's not a Winamp2-alike media player anymore, very well made in it's own right and on a really good way to become BMP 2.

If emo overwhelms you and the winamp2 GUI gives you a warm buzz then that's long time no reason to say that players with entirely different concepts are a dead end.

Milosz

PS: I've been writing for magazines too and I can only give you the hint that you really should stop doing that unless you are willing to do the basic fundamental stuff that needs to be done before writing an article, starting with proper background research.

>> although, from what I’ve seen, he hasn’t agreed with Peter on what XMMS’s replacement needed.
> We didn't "ask Peter" since we don't have any obligations towards the XMMS/XMMS2 developers

Just because you didn't ask him doesn't mean you don't disagree with him. At no point did I say you needed his permission. You're going your way, and he is going his. I don't see why you disagreed with that; is BMPx a XMMS2 clone and you forgot to tell everyone?

Also, by making BMPx what it is now, you're essentially saying the Winamp look/feel isn't the way to go for a music player, which Peter did copy at first. All "post-Winamp" players are working towards that goal; iTunes, Amarok, Exaile: they all are trying to make more efficient ways of playing and maintaining your music collection. You disagree with Peter on how that is supposed to happen.

> No one from the original BMP team as far as I know works on other media players. (Sounds like
> you're trying to tell a goodnight story for children to sleep: "And if they didn't die, they
> still live somewhere out there, working on other media players!")

Descender and Quirk, both former BMP developers, have gone on to work on LAMIP now.

> I know the actual facts, and you've just got them so plain wrong that you either made it all
> up or deliberately forged them so your article can make a point on Audacious.

Oh really? Its kind of funny that several people who were actually there when this happened say you are wrong. I saw it happen too, are you saying I'm lying as well? Hell, Chainsaw personally shot you down in your previous comment on this article just because you got stuff so wrong.

If you want people to take BMPx seriously, then stop trolling in blog comments, and start coding.

This article is a joke; Patrick McFarland is good friends with one of the primary Audacious developers and is a known internet troll. The bias he is showing here in this article is obvious, if FSM wants to be taken seriously then they need to dump people such as this contributor and quickly.

If you want to see examples of Patrick’s trolling adventures, just ask and I’ll provide links. His blog is one example of it.

XMMS2 is not a fork of XMMS - there's no code shared between the two projects.

There is no 'GTK2 support' in XMMS2 - XMMS2 is a client-server system, and the XMMS2 daemon (xmms2d) doesn't have any GUI code at all. http://en.wikipedia.org/wiki/Xmms2#XMMS2_and_other_projects explains 2 other uses of 'xmms2' which may be confusing. In short, those other uses had nothing to do with the current XMMS2 project, and are now defunct.

XMMS2 doesn't have 'input' plugins like XMMS. The sentence 'Peter also wanted to split plugins into “input” and “transport” categories' doesn't make much sense, since it was the 'input' plugin concept that got split into 'transport' and 'decoder' plugin concepts in XMMS2.

There's no doubt that XMMS2 will die out, just like most other systems die out - it remains to be seen just how this will happen. :)

Yehaw, please lay off using troll as a derogative term, some of us feel tenderly towards the title :

http://www.trolltech.com/

So when are some of you spastics going to start using a proper toolkit? My hands are currently tied apropos media players, since I can't find anything like audacious (or even any of its blotchy inbred xmms siblings) which is written against either the Qt libraries or KDE libraries.

xmms does what a player needs to do. Audacious seems to follow in its stead.