Market share numbers in free software is a rather dubious thing and tend to reflect more often the wishes of the quoter than any true objective measurement. I still dare to claim thought that XMMS has historically been the most used GUI media player on Linux and FreeBSD systems and maybe still is. Still there have been a lot of alternatives popping up all hoping to dethrone XMMS over the years and maybe the time has now come when either there will be no clear leader or someone else will ascend. One of the alternatives I really like is amaroK.
I came in contact with amaroK and its developers through my participation in the GStreamer multimedia framework project and my work for Linux multimedia specialists Fluendo; Due to this tend to try out as much of the GStreamer using software being developed as possible, both to provide the developers with feedback, but also to see if they fit my needs better than my current choices.
amaroK tries to both offer some of the features that people love in XMMS and at the same introduce new concepts as those coming from the iTunes style players. So in order to let more people learn of this wonderful application and its developers I decided to conduct this interview with the core amaroK developers.
Christian: Please give a short introduction of yourself and why you started or joined the amaroK project?
Mark: Hi, I’m Mark, 29, from Germany. I’ve studied Computer Science and have always been interested in multimedia programming, starting with demo-scene coding as a teenager. I founded the amaroK project in 2002. Back then I was a user of XMMS, which I considered the only "serious" audio player for Linux, regarding its flexibility and large feature set. Still, the user interface was a constant source of anger for me. Why did I have to press "+" for adding files, and "-" for removing them again? Could that not be made simpler? I came up with the idea of a midnight commander like interface: You get two view panes, on the left side your files, and on the right side your playlist, and all you have to do is simply drag and drop files. So I started to implement a player around this idea, and the project gradually picked up momentum, with new developers joining.
Max: I’m a recent graduate looking for an opportunity to work in the software
industry. I’ve been programming for years, but didn’t discover Linux until 2
years ago, and after that it didn’t take me long to get into open source
Leinir: I’m Dan Leinir Turthra Jensen, known by most as Leinir because, well, there’s just so many Dans around. I randomly help out with tidbits around KDE, though nothing extensive or high profile. I’m the author of the Reinhardt widget style and icon sets, and I mainly talk a lot, trying my best to keep people to the user interface guidelines and the new HIG.
There are a large number of music players available already; JuK, XMMS, Rhythmbox and Zinf to name a few. What made you decide to start a new project instead of joining one of the existing projects?
Reasons are twofold, really. In the first place I did not see much chance to implement my ideas in an existing application, as they would have required radical changes to the GUI. Also, I preferred a KDE toolkit interface and wanted to use C++, which ruled out projects like XMMS or zinf. Well and the second reason is, I needed a challenge, I had not programmed for quite some time and was beginning to fear I had lost it! Shortly after starting amaroK my girlfriend had left me, I was feeling very depressed, and to cope with my state of mind I started coding like a maniac, spending every free minute on the source code. I became quite obsessed, and realized how good creative work feels. Then after some time Max, Muesli and Leinir joined the project, and the fun really started, since we were now a team. I’ve always loved teamwork, and even more so with the great people we have in our project.
I’d been using XMMS since I had switched to Linux and had never been a huge fan.
I downloaded amaroK 0.6.0 one day after seeing it announced and immediately
recognized a media player that had potential. At this time JuK wasn’t nearly
as mature. I’d been looking for a way into a more official KDE project and it
seemed the next step was clear.
Well, I joined the amaroK after it had it’s first public release. It was a very powerful player with some really good features, but the usability of it didn’t just lack, it was simply horrible. I’ve been spending the last year trying to help out with finding features that would make sense from the user’s end of it, as well as sort out the problems with the user interface. The First Start wizard is my fault for example.
Christian: What do you see as the best features of amaroK?
One of amaroK’s strengths is the integration of both file and library based
media access. You can directly access your filesystem with our powerful
File-Browser, just as you do with XMMS, and drag some tracks into the
playlist. This is is a very quick way to just play a couple of tracks. And
you can utilize the comfort of our Collection database, which is a music
library. The Collection offers an organized view on your music; it can sort
by selected criteria, like Artist – Album, or Year – Artist, and shows the
information in a tree view. amaroK always lets you choose the best tool at a
I have to say the developer team. Having worked with those guys for over half a year now, I can say that there are few people that care more about their software and their users. The patience they show with some of the people they deal with is just amazing.
Other nice features include lyrics, cover support, and the context sidebar in general. And that these this just work, or at least we hope so.
Christian:Any specific features apart from those mentioned above that users seems especially taken with?
The automatic album cover retrieval is a very popular feature with our users.
It fetches album images from the Net or from your harddisk and displays the
right image along with the music you play. Not only does this look extremely
cool, but also it helps to associate the music with your memory – one image
says more than 1000 words 🙂
What was the initial background for you looking into using GStreamer for AmaroK ?
Once upon a time amaroK was an aRts-only player. aRts support was hardcoded into the application, and could not be switched. At this time I was quite impressed by aRts’ design and feature-set, as I thought it was a very powerful multimedia framework. Staring at its source code I even became a bit of a fan of the author, Stefan Westerfeld, who came up with aRts at a young age, which was an amazing achievement. Unfortunately, aRts had always been a one-man-show, and as Westerfeld abandoned the project, the problems became more painful by the day. aRts was more or less unmaintained, and missing important features we really needed. So we began looking for alternatives, and GStreamer, although quite immature at that time, was the most promising candidate. But we did not want to risk placing our bets on the wrong horse again, so we invented amaroK’s pluggable engine system, which makes it possible to switch between multiple backends. GStreamer is now our default backend, and in general we’re quite happy with it. More important still, our users enjoy using it as well.
AmaroK also use libvisual, a new library meant to be a cross player library for doing
visualizations. Is using existing libraries for functionality a clear policy from AmaroK or was it simply the featureset of libvisual which attracted you to it?
Initially we were attracted to libvisual by a posting to our mailing list. A user had recommended the library to our project, and we became interested in the idea. Max was the first to actually check it out and quickly came up with an interface for amaroK, which worked very well, despite the relative immaturity of libvisual at that time. Nowadays Synap the crazy Dutchman, founder of libvisual, hangs out in our IRC channel, so we have a great relationship with the libvisual team and can synchronize releases, request features and so on. At this point I would like to invite everyone to visit us on #amarok on irc.freenode.net, as our development process is very much IRC based, and we usually hang around there most of the time.
Max: We like to concentrate our efforts on the user-experience rather than the
engineering components like a whole new database, or multimedia framework, etc.
You can only really hope to do one thing well in my opinion. I recently looked
through a few hundred descriptions of media-players on Windows looking for
ideas. I discovered that generally Windows’ media-players are devoid of
functionality. They have to concentrate on making the entire package, so they
tend to put the most effort into supporting the media formats, and the interface
is usually appalling, or just basic, or they focus on one ‘interesting’ feature
and ignore everything else. Winamp
suffers a little from the do everything approach, but has done better than
most because they are pluggable and have attracted a large crowd of developers
that fill in the gaps where possible.
We were attracted to libvisual because we had already started making our own
visualization system, we were going to try and make it cross-player and easy
for other projects to adopt. We discovered libvisual and realized they’d do a
better job, and we could always help them out. We complement each other very
Though I’m not a developer, it seems to me that the way amaroK is designed clearly indicates that if there is a library specifically designed for something (and not in the least making sure that it actually works as intended), we will use it. For example we rely on TagLib to do tag reading. Also amaroK itself does not have a decoder built in (something a lot of people seem to be confused about, possibly because they are used to using programs like XMMS where the decoder engines are bundled with the rest of the program), so also here is a dependency on external libraries.
GStreamer has historically had closer ties to GNOME than KDE; did you feel the GStreamer community accommodated and welcomed for you as a KDE developer?
Oh yes, the GStreamer community has been very helpful and quite friendly in general. That’s one of the big advantages of GStreamer – it is a true community project. On IRC you can basically get help 24/7, and talk to the core developers personally; This way problems are usually sorted out quickly. This year Christian and Wim from GStreamer attended our KDE conference "aKademy", which was pretty cool, as we could chat a bit in person, have a few pints and discuss multimedia stuff.
Max: I never once felt GStreamer was a GNOME specific project. And even if it was that wouldn’t have stopped us from using it in amaroK.
Multimedia is a field riddled with US software patents. What are your thoughts on the
dangers facing GNU/Linux/FreeBSD multimedia and its developers from patent holders
desperate to hold on to their monopolies or just milking the unwary developer?
Like most open source developers I believe that software patents are a really bad idea, and I’m afraid of the consequences in the long run.
Max: As a young European developer who wants to make a living from software, patents scare me a great deal. I feel that patents are generally stifle innovation in all
industries bar a few, notably industries where the cost of research is so
high that innovation would not occur at all without the patent incentive.
Otherwise I feel that the incentive to make money is sufficient for most
creative people. I am already put off development now and in the future due to
the very idea of software patents. I can only hope the world sees sense.
Quite frankly, I am scared. While the US patents have no influence at all on e.g. amaroK, since the development is hosted outside of the US, it will mean a lot of work will have serious problems being accepted in the US, and while you might argue that that is only one part of the global market, unfortunately it is a very large part of it. So I am very much hoping that the US courts will interpret the laws in a way that is beneficial to open source development.
You have been working on both a crossfade plugin and a kioslave plugin for GStreamer how has that been?
KIO support what relatively simple, but crossfading turned out to be a real beast and took a long time to get right; it drove me to the edge of insanity. I was starting to throw my food around the room and talked to the carpet, it was that bad. Don’t try this at home, kids! To summarize, getting the basic design right was rather straightforward, especially with the generous help from Thomas Vander Stichele on IRC. amaroK was the first application to implement crossfading with GStreamer, so I did not have an example source for guidance. The hard part was to work around all those little threading related quirks in GStreamer, as the crossfader must use two threads simultaneously, and exchange parts of the pipeline while it is running. One must be very careful not to produce audio dropouts and noises while new tracks are started and stopped. Fortunately, in the end it all worked out, I was quite happy with the result, and I had learned a lot about GStreamer programming.
What features are you most happy about in GStreamer today and what are you most unhappy with?
I’m happy with the general architecture of GStreamer (the core), its flexibility and the ever growing amount of cool plugins. One of the points I’m not so happy with is IO support. For accessing non-local protocols like http (for streaming) or ftp, all current GNOME based GStreamer applications relies on the gnome-vfs plugin, which depends on GNOME libraries. This is, of course, not an acceptable solution for KDE applications. So there were efforts by myself and others to offer KIO support, which is the KDE equivalent to gnome-vfs, but unfortunately KIO does not cooperate very well with GStreamer’s design, in the sense that KIO requires an qt eventloop, so the current solution is to run the kio plugin within the amaroK eventloop which I feel is a bit ugly.
In the long run I think it would be better if GStreamer offered its own integrated IO subsystem, which would not depend on GNOME or KDE, or maybe that both gets replaced by a freedesktop IO subsystem.
What are your upcoming plans for amaroK?
One of the features we are working on is a flexible plugin system, which should allow to extend amaroK in useful ways. For instance once could add a new browser plugin, perhaps for accessing portable music players, or playlist enhancements. My vision is to make the plugin interface accessible for multiple languages, not only C++. I think it could be a very attractive option to program a plugin in scripting languages like python or ruby, which would allow rapid development without long compile cycles.
More of the same, really… Helping with cleaning up the interface, trying as well as possible to keep with the HIG and other specifications put out by the KDE usability team. Also, I am currently helping with the new layout for the Context browser, which will eventually mean that it will be possible to theme the Context browser very easily, simply by using CSS. There is a screenshot of some early development of it in the amaroK In Development screenshot gallery.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.