Hoppa över navigation

Category Archives: xmms2

Having spent quite a few total hours in GDB over the past weeks it started to get boring to print *res->value.list->… etc over and over to see what weird value was harassing my tests. I had heard that GDB had gained Python support  some time ago and decided to write some useful tools for debugging XMMS2 related code.

This is now what it looks like when you print a xmmsv_coll_t:

(gdb) print *coll
$11 = {
  "attributes": {
    "type": "id"
  "idlist": [], 
  "operands": [
      "attributes": {}, 
      "idlist": [], 
      "operands": []

…and a regular xmmsv_t:

(gdb) print *fetch
$15 = {
  "type": "cluster-list", 
  "data": {
    "type": "organize", 
    "data": {
      "id": {
        "aggregate": "first", 
        "type": "metadata", 
        "get": [
  "cluster-by": "id"

The code is a bit under 100 lines of Python and should be a nice inspiration for people who still haven’t added this huge help to their projects. The code can be found here, and checked out via:

git clone git://git.xmms.se/xmms2/xmmsgdb.git


As it’s always been a bit too far behind the scenes I wanted to take some time to describe what measurements has been taken to increase the quality of XMMS2, and what the future has in stock.

Today we have a basic unit test framework built on top of libcunit. To reduce boiler plate code in the actual test suites a number of macros have been defined. Here is an example of the basic structure of a simple test suite:

SETUP (mytestsuite) {
  /* setup what ever is needed
   * for each test case to run

  /* clean up such that the state
   * is restored to the state before
   * SETUP (mytestsuite) was run.

CASE (mytestcase1) {
  /* the actual test */

CASE (mytestcase2) {

To guarantee correctness SETUP will be executed before each CASE is run, and CLEANUP will be executed after each CASE has finished. Additionally the whole SETUP, CASE, CLEANUP is wrapped by the following checks both before and after:

VALGRIND_COUNT_LEAKS(leak, d, r, s);

This imposes no runtime dependency but injects markers such that if the test is executed under Valgrind, each test case will be inspected for memory leaks independently, which causes that test case to fail if a leak is found.

That covers writing test cases and validating their resource management, next up is getting a clear view of what has been tested and this is where coverage reports come into play. To get coverage reporting, via gcov, the –coverage flag is appended to both CFLAGS and LINKFLAGS in the build system. When running the tests a heap of .gcda and .gcno files will be emited which among other things contains the metadata about what lines were executed. To produce something that’s easy to inspect lcov processes these files into a heap of HTML files using the following command line:

lcov -c -b $base-directory -d $metadata-directory -o coverage.info
genhtml -o cov coverage.info

The $base-directory in this case is used to resolve relative paths as our build system outputs its artifacts in a sibling directory of the source directory. So for example the source files will be called ”../src/xmms/medialib.c”, where ”..” is relative to ”_build_”. The $metadata-directory is the directory to recursively scan for .gcda files. See the man page for further details.

So we now know that our tests produce the correct result, they don’t leak, and we’ve verified via coverage that our tests cover the complex code paths we want them to. Already this gives us a lot of comfort that what we’re doing is correct, but there’s one more tool we can use to increase that comfort and that is the beautiful free static analysis tool from the clang project. To perform a static analysis of the XMMS2 source code simply issue the following commands:

scan-build ./waf configure
scan-build ./waf build

After a while the analysis is done and you will be presented with a command to run which opens your browser with the static analysis report. This is the latest addition to our tool chain which will help us to increase our code quality even further, so there are still some warnings of different severities left which should be fixed.

Now on to the future. While working on getting Collections 2.0 into shape I started working on a comfortable way of validating the correctness while getting to know the whole concept and the code behind it so that I could easily modify its structure without breaking things.

First step was to build the data structures via the C-API like clients would, and some basic validation of the result. This turned out to be pretty verbose as the whole data structures would be written out in code instead of generated from some kind of user interface. The first step was to write a small JSON parser that constructed a xmmsv_t which could be used to build the fetch specification, so that by looking at a test for a second you’d know exactly what the result would be. After this the next obvious step was to construct a xmmsv_t from JSON with the expected result. Here a vision of an entirely code-free test suite started to grow, and some lines of code later a xmmsv_coll_t could also be constructed from JSON.

The envisioned test-runner is not committed yet, but what it does is to scan a directory structure like this:


And for each directory under ”testcases” it performs the same task as the current test framework does, but now in a way that makes it easy for non C-coders to contribute new test cases.

A bonus here is that it’s easy to re-use this collection of test cases for other types of tests, such as performance tests, which actually already works. When running the suite in performance mode another directory is scanned for media libraries of different sizes (500, 1000, 2000, 4000, 8000, 16000 songs) on which each of the tests are executed, and performance metrics per test is dumped on stdout.

The idea is that these performance tests will emit data in a format that can be used for producing nice graphs based on different metrics. The script that produces the graphs would take as input a number of test-runs, so that you could easily compare multiple versions of the code to check for performance improvements and regressions.

So that’s it folks, if you have recommendations on further improvements, don’t hesitate to join the IRC channel for a chat, or perhaps drop me a mail.

GSoC Mentors Summit in all glory, but all sessions and no hack made drax and me dull boys… enter Skidbladnir to bring joy to life!

After a day of slow sessions, me hacking on Abraca, while drax hacking on a new web 2.0 client we decided that enough was enough, time to get some collaboration going.

I actually came up with the idea a really long time ago, while Service Clients was just an vague idea in the minds of drax, theefer, and the wanderers.

As I live in Sweden, home of the fast Internets, I know that a whole lot of people would be very happy if their favorite music player had easy access to, everyones favorite, The Pirate Bay for getting more content.

A typical scenario would be that I was playing some song by Timbuktu, and my music player would automagically notice that I’m missing that new single that Timbuktu, one of Swedens most popular artists, officially released first to the world on The Pirate Bay *hint hint hint all other artists* and then present a link to that torrent for me to click on, and download using my favorite torrent client.

This feature is so hot that ALL XMMS2 clients should have it, thus we wanted to do this as a Service Client.

So late saturday afternoon just before we left Googleplex I started to update the xmmsclient python bindings to match the Service Client branch my student had written during GSoC. Meanwhile drax was working on getting his webclient ready and some helpers to count string distance between Freebase data and some mock Pirate Bay torrent names. Due to jetlag my evening ended early for me, but when waking up somewhere around 3AM I had a great message from The Pirate Bay waiting for me about getting early access to their upcomming webservice API. The rest of the sunday was spent frantically hacking the python bindings so that we could have a running demo before I had to leave for the airport and it worked! Around 2.45PM we made the first working request from the service client and I ran to the bus.

So to summarize what this client does:

  1. Register as a service client that accepts an artist (string) as argument.
  2. Accept request.
  3. Find albums by artist in medialibrary.
  4. Find albums by artist in Freebase.
  5. Find albums by artist in The Pirate Bay.
  6. Subtracts the albums in medialibrary from the albums returned by Freebase.
  7. Calculates string distance from what’s left of Freebase result with The Pirate Bay result to get good names pointing to correct but crappy torrent names.
  8. Return a list of albums missing in the medialibrary by some artist, with links to download.

Right.. and the name Skidbladnir refers to the ship of Freyr that sails the Scandinavian intern^H waters with fair wind, and folds easily into ones pocket.

PTSD, I miss google…
I want to go back…
I want to hack…
take me back…

I’m not a GUI designer, but (…) I still get ideas every once in a while. My last post on the subject turned into an OpenMoko client based on the sliding GUI idea thanks to Anders. This time I present to you three more ideas.

First out, an MTV-isch OSD.

The idea behind this is obviously MTV. Over the years they’ve outdone themselves in the design of new fresh OSD’s to present their artists. The OSD’s are often animated, and always very pleasant to the eye. When looking at the OSD’s available for different music players, none of them comes near. Som just print text on the screen, that disappears after a couple of seconds, some add fading to make it a bit prettier, some use the notification area of GNOME to present the current artist, and some use Growl on OS X, and none of these look very pretty, they just look like half-assed attempts at presenting the current song.

A year or two ago I was into writing C# bindings for XMMS2, and I whipped up this example that made an attempt at creating an animated OSD.

Here is the screencast.

This is obviously butt ugly as IANAGD, but it shows a glimpse of what may be the future of OSD’s. Perhaps using EFL might be the way to go to get thos animations blinging. Anyway the code and the tools are of no importance without a good design, so copying designs from MTV to start with, and then evolve those to something new, fresh and free could probably lead to something interesting.

Another interesting design is the flowers from the Moppi Productions Assembly 2004 invitation demo, linked to the music. This could definitely be written as an OSD to XMMS2, as we now have a great visualization API thanks to the Google Summer of Code. The demo is for Windows, but works great in wine. In an OSD these flowers would grow out around the OSD box, and then anti-grow back when the box is to be closed.

Second out, drag-n-drop cover art.

I have no idea why many of my ideas are related to cover art, as I don’t really think they are that important, but here is another good thing to have. The ability to drag an image from Firefox, drop it in the cover art area of the client, and the client downloads the image and sets it as the default cover art of the current song (or album). The point here is that it should be as easy as possible to set the cover art. It’s a changeable target, and it should be easy to change it. Other than drag-n-drop it should definatly support copy/paste too. Drag/drop, copy/paste should ofc both handle urls, and data pasts/drops.

And here’s the obligatory screencast.

Third out, LastFM buttons.

The way LastFM works is a bit disturbing to the music player. When a LastFM stream is activated you either have to change the GUI, or be dysfunctional. The last alternative sucks a bit, as the power of LastFM is only unleached if you can skip tracks, otherwise you could just aswell listen to regular shoutcast. I prefer music players with three buttons for playback control, [prev, (play|pause), next], so some days ago I realized that this happens to be the same amount of buttons required to control LastFM, so why not combine them? I still haven’t decided in detail how this should work, but I wrote a small demo application that, when a LastFM stream starts, the three playback-buttons become LastFM buttons. You can access the original buttons by holding the mouse over the controls for a few seconds, this could also be handled with holding shift or something.

Anyway, here’s the obligatory screencast.

And this is all for this time, hope some of the ideas are put into use in some clients.

Time to indulge in all the Christmas food. Merry Christmas everyone! \o/

After having talked about setting up a BuildBot service for XMMS2 for 6-7 months I finally got my shit together a couple a days ago and did it.

For now we have three slaves running, Debian Etch, mingw32 and Freebsd 7. The latter two have already helped us locate one bug each and a fix for one of them has been merged. In the near future a Mac OS X slave will be added, and Anders has mentioned that an ARM Scratchbox slave might happen.

The BuildBot setup currently online is just the first step in improving the quality of the XMMS2 project. When DrK is out and the Google Summer of Code testing framework project has been merged, tests will automatically be run on all builds, and hopefully catch even more bugs thus save a tear or two from our users.

Also, when I get the time I will make the mingw32 slave produce snapshots for download to make it easier to run XMMS2 on that strange OS we are forced to use in unfortunate times.

Click here to get the latest build status.

Update: The ARM slave is now up and running.

Update: The Darwin slave is also up, and yet another bug found.

In the world of XMMS2 there are a heap of clients that more or less rip the design from something that already exists. Some clients have potential, while a lot of clients are just ”Hey, I has writes my 0wnz0r music player!! zomgbbqzuhl!!11!”. Though this kind of sucks when new users find XMMS2 and have to wade through an ocean of crap, it also reflects how easy it is to whip up a GUI connected to a real application so that you can try out new concepts in a live environment without much hazzle, which is a good thing<tm>.

I myself am far from a GUI designer, but every once in a while I come up with some idea that I actually decide to implement. The downside is that I’ve never as of yet put my ideas together into a whole client but instead they end up in my ~/dev_home directory and bitrot, so here comes two ideas that I haven’t seen anyone experiment with, that with some luck might get picked up by some client author.

First out, an attractive info dialog.


Basically looks like the standard old info dialog that we have seen before, but with the coverart switcher added. The idea is that when you drag your mouse over the image you get a number of alternative images. We have the xmms2-covers client that surfs the net for coverart and then adds them to the entries in the media library, it’s pretty common that some art is found at multiple places in a variety of qualities, and the user should easily be able to pick one of them, or optionally pick one from file.

So some weeks back I wrote two implementations of this kind of view.

clutter based version
gtk based version

It’s not a feature that propells your client to the moon with, but imho also the tiny parts should get their fair share of time and thought to give a rich user experience (without offending the user with too much bling ofc).

Second out, Sliding GUI.

The idea was to have a simple GUI that only showed information to the user relevant to the current use case. This was accomplished by having a small number of cards (3 in my example) that slide, like the desktop switch effects on Mac OS X and Compiz. The first card was to show coverart in 90% of the screen and then artist – title (and maybe album), the second card held the playlist, and the third card was undefined. By pressing tab the next card slides in, and when reaching the last card, a final slide occurs passing all cards until the first card is visible. Later I realised that this is kind of how the iPod works, evil Apple manipulating my brain! 😉

Anyway, here’s a screencast.

This idea could actually be implemented for Esperanza. There would be two cards then, one for coverart/artist/title (card A), and one for the playlist (card B). When moving focus and/or mouse out from Esperanza card A would be shown, and when focused/entered card B would be shown. Alternatively card B could be shown on focus/enter, and after a timeout card A could be shown.

Conclusion (IANAGD)

I think it’s more important to question the reason for each part of the gui, than to have a gazillion features, and it would probably not be a bad idea if the GTK client writes unite, and some goes for the QT client writers. Also, with the exception of Euphoria, no clients as of yet take advantage of animated GUI components. It’s very easy to add animations here and there without making the GUI unusable, and it can add to the user experience, so why not take advantage of it? Oh, and I also want to see more web-awareness folks!

There, I’ve said it, time to hit the sofa and wait for the perfect client<tm> 😉

(Oh, and the code for the above hacks exists, ask me on irc if you really want to see, mostly really really …. *zzz* …. really nasty hacks).

I’ve started my voyage into bluetooth land now and it has been some confusing days.

I spent about three hours on google just to find out that you couldn’t connect to localhost with bluetooth. This means I have to do some of the work correctly the first time instead (or debug the application on the phone, bleh). About 10 minutes later I luckily found out that it was possible to write the Service Discovery part against localhost by using the address ”0xFFFFFF000000”. Then I went on to figure out how this UUID-stuff worked and now I can actually discover my ”XMMS2 Remote Control” service from my phone. Yey! I used AvetanaBT to implement this part. It is a JSR-82 compatible java framework that runs on J2SE.

Today I’ve been learning about GIOChannels and refreshing my UNIX socket programming knowledge. I realised that I could write quite a bit locally by writing a J2ME compatible java Client that connects over tcp to a test server. I’ve given up on extending Bemused’s protocol as it doesn’t fit my needs at all. So this evening/night have also been used to figure out what the protocol should look like, and a some minutes ago I compiled the first working version that communicates ints and strings.

Requesting the playlist for example looks like this:

Client -> Server :

Server -> Client :

I will probably not document this protocol as I intend to write the server as platform independent as possible. It currently runs on Linux, but with some minor changes it also compiles on FreeBSD. The bluetooth connection will be abstracted so that it can be replaced by tcp if someone cares to write such a module, or perhaps diffrent bluetooth apis (OS X, Wintendo). And maybe the player communication will be abstracted so that any music player with similar features (playback, playlist, medialib) can benefit from this project by adding a corresponding module.

When I originally wrote the build.xml for this project my main goal was just to get it to work. This lead to a really crappy handling of preverify where you had to add the class files manually as preverify doesn’t search subdirectories for class files. So today I finally got tired of having to edit build.xml every time I added a new class, or renamed an old one. Unfortunatly Google let me down except for some outdated J2ME Ant extensions, but after deciphering the Ant manual I came up with this vanilla Ant code:

<!-- Find class files. -->
<fileset dir="${build}" id="tmp">
      <include name="**/*.class">

<!-- Convert filenames to valid preverify input. -->
<!-- From: /absolute/path/to/package/SomeFile.class -->
<!-- To: package.SomeFile -->
<pathconvert pathsep=" " property="unverified" refid="tmp">
  <packagemapper from="${build}/*.class" to="*">

<!-- Execute preverify on classes. -->
<exec dir="${build}" executable="${j2me.bin}/preverify">
  <arg line="-classpath ${classpath.j2me}">
  <arg line="-d ${preverify}">
  <arg line="${unverified}">

Maybe this will save someone else’s time.

After being convinced by a friend of mine that J2ME hacking could provide hours of fun I was determined to give it a try. My earlier attempts had only been with the basic forms, and I’d found it hard to setup a sane build environment without using Nutbeans or some other IDE.

After reading about MIDP packaging, and finding about about tools like preverify and other stuff, I finally had a nice and small development environment (vim+ant+j2me) without wasting 1GB of ram.

A couple of days earlier I had seen Opera Mini for the first time and I was surprised about its clean and good looking gui so I planned to do something similar. Now almost a week has passed and my GUI toolkit is comming along well. It looks just as good as the one Opera Mini uses, with some parts better looking, and other parts not yet implemented.

Next, the bluetooth part. When the project idea came to mind I thought any bluetooth enabled phone would do, I was wrong. Bluetooth phones predates the J2ME support for bluetooth (JSR-82). After some googling I found out that my phone lacked JSR-82, but the timing was perfect as my 24 month mobile phone contract went out this month. Some clicks later I had ordered a new mobile phone with JSR-82 (Sony Ericsson K750i). With some luck it arrives by the time the GUI toolkit is mature enough.

There are other projects that does this exact task for other music players. I’ve been looking at Bemused which has both Winamp and XMMS support. Bemused is mostly for Symbian based phones, but an outdated J2ME implementation exists. My plans are to be compatible with this protocol if it doesn’t require too much work. The protocol however lacks support for coverart, medialib browsing, so at least that has to differ. When the time comes I’ll try to contact the Bemused people to see if they’re interested in updating their protocol.