These are my notes to get useful cross-compilation, even with autotools, and GStreamer stuff.

This has been a known fact inside Nokia (MeeGo) for quite a long time due to various performance issues we’ve had to workaround, but for some reason it wasn’t acknowledged as an issue when it was brought up in the mailing list.

This is a continuation of my previous post. Based on the feedback I decided to do two things; investigate the strange FLAC high CPU usage with FFmpeg, and get more accurate measurements.

GStreamer sucks

It turns out that GStreamer flac parser uses four times more CPU than FFmpeg’s decoder. Thanks to perf, I was able to quickly figure out the biggest offenders: GStreamer’s horrible bitstream reader (GST_BIT_READER_READ_BITS) was by far the worst.

53.03% libgstbase-0.10.so.0.26.0
24.78% libavcodec.so.52.72.2
17.35% libgstxiph.so
1.52% libc-2.12.1.so

This is on my laptop just running the parser (filesrc ! flacparse ! fakesink), in total it was taking 2.67s.

After reading the code and trying different things, I decided to go for something similar to what FFmpeg is doing, and I also borrowed pieces of the architecture-specific optimizations, now it even looks ok:

72.68% libavcodec.so.52.72.2
14.20% libgstxiph.so
4.00% libc-2.12.1.so

And it takes 0.81s.

But how much would this affect battery life on the N900?

Smart battery script

I tried different ideas, and after refreshing myself on statistics I wrote this script in Ruby that runs all the tests, gathers the battery capacity in a separate thread, and finally generates a report per test. Much easier than before.

Since I’m already working on FLAC, I decided to also apply some patches that split the decoder from the parser, and optimizations from Måns Rullgård (good thing I grabbed them because he seems to have left the project and deleted his repos).

Battery life

Battery drain

So, yeah, much better now

But how credible are these results? Well, judge by yourself, listed below are the raw measurements, the samples are the differences in capacity (mAh) measured each 10 minutes, from which the drain and battery life are calculated.

== baseline ==
samples: 3, 3, 3, 3, 4, 5
drain: 21.00±1.87mA
life: 65.39±4.77h
== av flac ==
samples: 9, 8, 8, 8, 7, 8, 7
drain: 47.14±1.45mA
life: 28.19±0.87h
== flac ==
samples: 11, 11, 11, 11, 11, 11
drain: 66.00±0.00mA
life: 20.00±0.00h
== av mp3 ==
samples: 11, 11, 11, 11, 11, 10
drain: 65.00±0.91mA
life: 20.33±0.30h
== nokiamp3 ==
samples: 12, 12, 12, 12, 12, 12
drain: 72.00±0.00mA
life: 18.33±0.00h
== av vorbis ==
samples: 10, 11, 11, 10, 11, 11
drain: 64.00±1.15mA
life: 20.67±0.38h
== vorbis ==
samples: 19, 18, 18, 19, 18, 19
drain: 111.00±1.22mA
life: 11.90±0.13h

If you are interested in the code: gst-av, gst-maemo-xiph. Enjoy

So, I’ve been working on gst-av, a GStreamer plug-in to use FFmpeg codecs (only audio for now), in order to get it in good shape for ogg support. First, I had to fix oggdemux and flacparse to be compatible with tagreadbin, it seems I managed to do it (with the help of a patch from Sreerenj Balachandran), so now the custom tracker extractors are not needed any more.

It’s time for the second release of scrobbler for Maemo featuring support to mark tracks as “loved”.

There have been many improvements over the 1.0 release:

• Support to “love” tracks
• Detect network connectivity
• Proxy support
• Support for Now-Playing

Also, I had to rename it from maemo-scrobbler to Scrobbler for Maemo due to trademark issues,

Here’s a screenshot:

This has been ready for some time, but I haven’t managed to make the release. All this time I’ve been testing it, and it works fine

It was quite complicated as I needed to write a D-Bus service first, and then write a separate Hildon Desktop widget to put some UI on, not to mention to write a lot of code to authenticate to last.fm web services. But it’s there now, and it works.

It’s now pushed to Maemo extras-testing, where you can test and vote up.

I’ve been watching some videos from Dan Pink, an American writer that concentrates on the science of motivation and I think they’re actually very interesting for most people, but specially reassuring for FOSS people…

If you ask an artist why they became an artist, a lot of them will say: I can’t do anything else; I have to do this… It’s the same thing. — John Yodsnukis

Dan Pink argues that for most of the tasks of the 21st century (which are more right-brain thinking), carrot and sticks (extrinsic motivators) don’t work, instead, intrinsic motivators should be used.

RSA Animate – Drive: The surprising truth about what motivates us

What Drives Motivation in the Modern Workplace?

And now that we are on the subject of creativity in work, Charles Leadbeater makes a very good argument about why radical innovation mostly comes from amateur professionals rather than traditional corporations.

Charles Leadbeater: The rise of the amateur professional

I got tired of waiting for my patches to be merged into mafw-lastfm, so I continued with my project which I decided to name maemo-scrobbler.

maemo-scrobbler is a scrobbler application (last.fm/libre.fm) for the Nokia N900 that listens for events coming from the official media player app through MAFW.

The inspiration (and some code) comes from mafw-lastfm which does basically the same thing, but lacks some features. However, the code-base of maemo-scrobbler is completely different as I wrote it from scratch. First, I wrote a simple libscrobbler library which uses libsoup and a test application that can be easily run on the desktop. This way I was able to test the main use-case throughly.

Compared to mafw-lastfm, maemo-scrobbler has:

1. Support for multi-scrobbling (both last.fm and libre.fm at the same time)

   Includes a song queue per service.

2. Improved song queue handling

   Since internally it uses libscrobble (which is independent of MAFW), the important code can be easily tested on desktop sw, and it has been done so… throughly.

   It doesn’t matter how flaky your network is, or that the servers are down, the songs will be submitted.

3. Permanent storage

   The song queue is not lost, even on crashes, device reboots, or software updates.

4. Video clips are ignored

   Small feature, but important.

In other words: maemo-scrobbler Just Works™

It’s now on extras testing, please give it a try and vote up.

For more info and the source code, check in github.

Hi,

I have been baffled by this bug report that appears in the logs as a constant reconnection, but everything seems to be working fine, except that network usage goes to the roof (as long as battery drain).

Finally, I was able to reproduce and hunt down the problem, and I found it would only happen if:

1. You have a pending offline message
2. You are on Daylight Savings Time

Then, msn-pecan will be stuck in a loop trying to authenticate to retrieve the offline message, but thought the token was already expired =/

That’s why even though nothing changed in msn-pecan for the past months, users suddenly started to notice weird battery drain.

The fix, is this humongous patch:
- tm.tm_isdst = -1;
+ tm.tm_isdst = 0;

I wish I had caught this problem earlier to save people’s batteries. Oh well, the fix is already in Maemo extras-testing (telepathy-msn-pecan 0.1.0-0maemo3), please give it a try and vote.

Finally I managed to workaround a bug in Maemo’s 1.1 SDK. So now msn-pecan has been promoted to extras-testing.

Please vote up so it can go into extras.

Now, there has been some confusion about the other MSN solutions. So I’m going to explain why msn-pecan is better.

telepathy-butterfly

telepathy-butterfly is pretty decent, as it uses papyon (the MSN implementation to be used in aMSN2), however it has one big disadvantage; it’s written in python.

For starters, this means you have to install python and all it’s dependencies; which account for 20M. If that was not enough, python being a scripting language will probably use a fair share of CPU, which is not good for battery life.

telepathy-haze

telepathy-haze is just a wrapper for libpurple protocol plugins, and in fact, telepathy-msn-pecan does use a hacked version of telepathy-haze to do it’s job. So the battle is actually libpurple’s stock msn plugin vs msn-pecan.

The stock plugin was actually written mostly by me a long time ago, and although some things have changed, I’m still probably the knows that has a better grasp on it. So when I say “it’s actually pretty bad”, believe me; I know what I’m talking about here

However, the real problem is the lack of support. As can be seen on Pidgin’s bugzilla; bugs go there to get lost. Most probably if you have problem on the N900 with it, nobody will be able to help you.

Moreover, you would have to install the rest of the plugins at the same time, in total, you would need 6.3MB. And my bet is that battery life won’t be as good as with msn-pecan.

telepathy-msn-pecan

It’s written in C, it’s fast, it’s efficient, 1.5M, but more importantly; it’s supported. If you find a problem on the N900 you can file a report in our issue tracker, and it will be dealt with. The only problem is that as of 0.1.0-rc3, it’s not as stable as I wound want (the new features seem to have introduced some regressions), but the remaining issues will be fixed soon. However, don’t be discouraged of trying it; most people don’t have any problems.

It took me some time but I’ve finally managed to integrate msn-pecan to my N900 thanks to telepathy-haze and telepathy-extras. I haven’t really been using WLM for a while but I think that’s about to change

Why telepathy-msn-pecan when there’s telepathy-butterfly and telepathy-haze+libpurple? Well, each one of those have some limitations. telepathy-butterfly will depend on pymsn, which will depend on python, plus a bunch of python libraries, I have my doubts as to how stable it is, how efficiently does it use the network, and mainly how long will it take to graduate to extras, not to mention that the installation size will probably be quite big. For telepathy-haze you would need libpurple, which is built using the Pidgin source package and who knows when that’s going graduate to extras.

In any case, I just prefer msn-pecan because I know the code, and I know it’s more stable than libpurple’s stock one (which I wrote many years ago), it’s more efficient, and it has been widely tested on Pidgin (Linux, Windows, and N8x0), and Adium on OS X. Also, it’s more bandwidth efficient, specially at login time, which is important if you are using a cellular data connection Moreover, at some point it will be a standalone library with a native telepathy wrapper, so this was a natural step.

First I needed libpurple, but since it’s distributed along with Pidgin and there’s no easy way to build it standalone. I used libpurple-mini which is a redistribution of libpurple that’s easy to build, no extra fuzz, just the bare minimal dependencies, and a minimal build-system.

Then I took telepathy-haze, which didn’t require any modifications, and telepathy-extras which did require quite a bit. I also wrote simple Makefiles just to simplify the build.

Then I modified all the packages so that they don’t conflict with the system ones (libpurple, telepathy-haze, etc.), when they are finally available in extras. The result is a 300KB standalone package

Here are a few screenshots showing how nicely it integrates:

msn-pecan field in the contact entry

Some msn-pecan contacts in the all contacts view

As you can see it’s very transparent. Your contacts could be in Skype, MSN, GTalk, you would barely feel any difference, and the switch to SMS, or voice call is seamless. Kudos to the Maemo rtcomm team and Telpathy for achieving this!

So give it a try and report back any issues you may find:
http://code.google.com/p/msn-pecan/downloads/

Next step would be to submit this to extras devel, I think it would not have much trouble getting accepted in, any volunteers to do that?

Oh, and Merry Christmas!