Christian: What do you see as the best features of amaroK?
Mark: 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 time.
Leinir: 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?
Mark: 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 :)
Christian: What was the initial background for you looking into using GStreamer for AmaroK ?
Mark: 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.
Christian: 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?
Mark: 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 well :)
Leinir: 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.