Lightning talk for GUADEC submitted

My submission for this year’s GUADEC:

This is a _lightning talk_ about how the evolution from MAFW (Multimedia Aplication FrameWork used in Fremantle official media player) to Grilo (new multimedia framework for application aiming to provide easy access to many sources of media) and how they can work together to provide a better user experience and access to more media in the Maemo 5 platform (Fremantle)

Unbricking my SheevaPlug

More or less one month ago, my SheevaPlug went bananas and didn’t turn on again. After talking to a colleague at Igalia who googled a bit, we found out that it could be a problem with the power supply unit. The issue seems to be known and it happens when you keep an external harddisk taking power directly from the USB port for a long time. It seems that power is not enough and you get a burnt power supply unit.

What I did was opening the Sheeva and taking the power supply unit to electronics specialized shop in my city and they told me that they didn’t have so small power supply unit, but that I could use an external one. He explained me what I should do.

I needed a couple of pieces not to cut the new power supply unit cables and a soldering iron (with some solder, of course). Then I could cut the connector of the broken power supply unit as you can see in the picture:

Next step was soldering the red cables to the inner pole of the adapter and the black ones to the outter pole (if I am not mistaken, you can recognize in the picture that the outter is negative and inner is positive). As I was bad doing this manual works at school and I still am, we (my wife and me, yes the pole soldered by her was in a better shape than mine) had to insulate them with a bit of insulating tape. You can see this in the picture.

The rest was just putting the external power supply connector thru the hole left by the old one and keep the cables where the old one was. I connected it to the motherboard, closed it and voilà!

Now I have the again the Sheeva with the external hard disk, but I provide external supply with something similar to this not to have the same problem again, but I wonder if just using a more powerful power supply unit would remove the problem of having the harddisk with external an external one.

mafw goes Grilo

As you may know, some colleagues at Igalia are developing a framework to gather, browse and query multimedia sources called Grilo. Of course it is no replacement for GStreamer as it is at a much higher level and we are focusing in gathering, browsing and querying so far.

We were an important part of the main developers of MAFW, so in this case we are trying to learn from the mistakes and try to create a more useful and easy to use framework.

One of my first steps, as a test, will be creating a MAFW pluging for Grilo, so that we can have all sources managed by Grilo running on the Fremantle official media player (as soon as bug 9361 gets fixed) with the consequence of having integrated important and interesting features as Youtube, podcasts, Jamendo, Shoutcast and so on.

mafw-gst-renderer and volume management

In the beginning we are just having a volume in MAFW that we were just setting to the GStreamer. This was a bit complicated to maintain because you always have to be careful of resetting volume to the pipeline when you create a new one and even after some state changes, meaning GST_STATE_READY for example, what I consider a GStreamer limitation, BTW. Anyway, we kept that with a conditional compilation because running Pulse was hell inside Scratchbox, at least for me.

Maemo 5 does not have global volume (to be changed by a user) and uses Pulseaudio, as I just advanced. It defines several volume roles so we can say that volume is context sensitive, meaning that call volume is not the same as multimedia volume, for example. As Maemo can have more than one media player it was not a clever idea to define our volume and use it with GStreamer pipeline and if you also take into account that you need to have the same volume as the status menu volume bar, mission turns much more complicated. The idea was then to use Pulse directly through ext-stream-restore2 API (which I think is not merged upstream yet). One of the side effect advantages is that we do not need to store the volume between executions because Pulse does.

Pulse API has the ability of several kind of loops, say, a threaded mainloop and a GLib mainloop. For simplicity and as it was enough, we used GLib mainloop API.

Other issue was merging requests implementation. We implemented this by sending only a maximum of 5 changes per second, it is once every 200ms in order not to flood Pulse with changes.

One of the things I did not like too much was the hacks to reconnect to pulse if they failed. In those cases we were just crashing, but people did not like it, so we had to implement reconnection (IMHO Pulse should never crash either). The issue was failures during reconnection, which made us to write a hack to try reconnection after one second, until we get it. This solved the problems but it is a workaround, not a solution (which should be Pulse not crashing or reconnecting always fine).

You can take a look at the code at mafw-gst-renderer-worker-volume.c and mafw-gst-renderer-worker-volume.h.