Tales of software craftsmanship

Tales of software craftsmanship

GSoC: Beginning Amarok Mobile

When the Google Summer of Code program was announced again this year I decided to submit a proposal for a project that would hopefully take Amarok in a new and interesting direction.

My proposal was accepted, so this year I’m a GSoC student again, for my third time, working on an Amarok port for mobile devices, primarily tablets.

Why mobile? In the past few years some profound changes have been set in motion in the computing market. What we still call “desktops” might soon become mostly workstations and gamer rigs. We’re not there yet, but computers are already becoming increasingly mobile, invisible and wearable, and computing is becoming ubiquitous. In this changing environment, complex desktop apps like Amarok 2.x will have a harder time staying relevant, and are being challenged by leaner, simpler and flashier mobile counterparts.

Amarok has a strong brand and a good reputation as the ultimate music player for GNU/Linux systems, prominent features where Amarok innovates and excels are web services integration and smart context-sensitive information. I believe the Amarok team can take advantage of that and make a successful entry into mobile markets.

There is certainly a lot of work involved: the existing GUI simply would not work well on touch screen devices, and a lot of the underlying stuff is also not so well suited for a mobile app because it provides a very extensive feature set and requires a lot of dependencies.

The foundations for a mobile version were laid down about a year ago, when Amarok developer (and my GSoC mentor) Jeff Mitchell made some deep changes to separate Amarok’s core logic from “everything else”, including collections, the user interface, etc. However, not much happened after that besides maintaining this separation, so I simply figured that if we indeed want to see Amarok running on tablets and handsets the actual porting work had to begin.

So what am I aiming for? At this point, a platform that is accessible almost immediately is MeeGo (and Maemo 6), represented by the upcoming Nokia N900 successor and Intel x86 based tablets, as well as devices which come with other operating systems out of the box but have a MeeGo port. While during this GSoC project I’m focusing on MeeGo, when making technical decisions I will be taking into account their impact on possible future ports to other platforms.

This port will require a completely new GUI, but since I’m not a QML GUI designer (yet), so far I’m only promising to deliver the underlying stuff.

Until now, I’ve done a bit of work on yanking out Amarok’s core and building it with a minimal set of dependencies, and setting up a MeeGo development environment. The next step will be porting this core to MeeGo, and then building the required functionality on top of it while keeping the whole app light but smart 🙂

7 Comments

  • Reply Bugsbane |

    Sounds awesome! Especially if it can still use Amaroks online collections (eg Jamendo et al).

    I really hope you’re talking to the Plasma Active people…

    • Reply Teo |

      I’ve talked a bit with one of the Plasma Active devs, Amarok Mobile might fit nicely into Plasma Active’s vision if the timing is right.
      Since we’re reusing Amarok’s core lib, Amarok’s collection framework will likely be there. It remains to be seen which collections will make it and in which form, especially considering that in a mobile app we just can’t require nearly as many dependencies as in the desktop edition of Amarok.

  • Reply Tom |

    This sounds really cool!

    Something that I think would be cool on mobile devices (and also would benefit desktop), would be to decrease the wake-ups Amarok is causing (have a look at powertop2, if you are not familiar with it).

    For a reference, it should be possible (with gstreamer/pulseaudio), to do music playback with about 1-3 wakeups per second (see ). However, Amarok is currently causing ~150 wakeups per second when playing on my laptop, so there is definitely room for improvement 🙂

    I don’t know if this would all be solved by patching Phonon, or if there is also some wakeups being caused by Amarok itself. Since you are going to work on the underlying stuff, I thought I’d point it out.

    Should save quite some battery time!

    • Reply Teo |

      This probably needs to be patched in Phonon and/or the relevant Phonon backends. I’d need to check how many wakeups are caused when I get to a point where the mobile edition can play a track, and see what can be done from there.

  • Reply damian |

    I really hope that this work also helps amarok go on a diet, it’s the best music player I’ve seen, but when I want to just hear a song, amarok becomes too overkill, I don’t want to use any other feature than hearing music half the times, and the other half I want to read context information like wikipedia articles etc, and make awesome random playlists.
    The gui itself is unbearable slow on my netbook, and the open time is slow too.
    I don’t mean remove features, but they shouldn’t be in the way when I just want to hear a song.

    • Reply Teo |

      You’ll be happy to hear that the first part of this project involves putting Amarok on a very strict crash diet, and then adding only what’s necessary 🙂

      • Reply damian |

        Thanks!, amarok really needs that, I guess it will also benefit the desktop, good luck!

Post a comment