Grilo meets Vala

Last week, after the internal presentation of Grilo, I got pretty excited about the project: basically, using Grilo I could make epris consume feeds from Jamendo.

I started to generate the bindings for Vala. I never thought it could be that hard: the heavy use of atypical callbacks in Grilo made me find a bug in the code writer of Vala. And eventually I came with a small patch, which I’d just pushed.

Those problems brought into the discussion to use GAsyncResult within Grilo instead of the custom callbacks mechanism. We’ll see where we can go.

Finally I got my small test snippet. Cute, isn’t it?

Today also pushed another patches I’d in my Vala queue. The interesting part is, after talking with Zeeshan, I understood that the gstreamer vapi must be generated with the latest release of GStreamer. Something logical but I never stopped to think about it.


Back in August 2009 I was chatting with my old peers in Mexico, and they told me that they needed a JPEG parser element in GStreamer for their DSP accelerated JPEG decoder. So, I went to bugzilla and found a bug report about the issue and a proposed patch. But the published patch still missed some features so I took it and worked on it.

After attaching my first try, Arnout, the first author of the patch, came with some comments to improve the element. Several weeks after I retook the element and almost rewrote it again. So I was waiting for the OK from a GStreamer developer.

Finally, this week, Stefan review it and pushed it. Sadly for me, I didn’t notice, when I rebased my local commits, squashing my change set into one single commit, that this commit had as author Arnout, not me 🙁

Now the commit is under the Arnout’s credit.

Yeah, sometimes I’m so absentminded.

Ping DSP task node

DSP task nodes, under the TI Omap3 domain, are a separate execution threads running on the DSP that implement control or signal processing algorithms.

I’ve just pushed a rewrite for the ping dsp task node to my dsp-samples repository. It works with the dsp-ping program included in dps-tools.

An interesting thing is that it’s nearly 5 times smaller than the dll provided by TI:

-rw-r--r--    1 1001     1001         3920 Jan 19 15:01 pingdyn_3430.dll64P
-rw-r--r--    1 root     root        19816 Jan 19 14:44 pingdyn_3430.dll64P.bak

And I'm going to FOSDEM 2010 too!

And maybe I’ll talk about this in the embedded devroom… maybe…

Minimal CD Ripper

Back in London I bought a couple CDs. Obviously I don’t use CD players anymore, I mostly stream all the music I hear (jamendo, spotify, Though, if I want to hear music using my n900 without any network connection, I ought drop in there the music files. So, the solution is rip out the music from the CDs,
encode them et voilà.

The obvious solution to rip music is SoundJuicer, and I started to compile it within my jhbuild environment, but I found a huge list of dependencies which I didn’t want to install, such as brasero. As everybody knows the next logical think then is “let’s code a simple cd ripper”.

Vala was my choosen language (and don’t ask why). What I wanted was have metadata in the files (life without metadata is not feasible anymore), also I want to encode the files in AAC/MPEG4, and finally I didn’t want any user interaction: just run the program and have my directory with my music.

The first problem I found was that Vala hasn’t bindings for libmusizbrainz, so I started to cook one for libmusicbranz v2.x, which I found terrible bad to port to Vala and also it is already deprecated. Then I cooked another for libmusicbrainz3.

After that, I also found that GstTagSetter wasn’t bind to Vala either, so I made the patches for it and another for the GstIterator.

Solved all those issues, finally I came with my mcdripper!

Ah, by the way, it uses async methods, so you’ll need a recent Vala (I use the git’s version).

And finally I’ve been ripping my new CDs and storing the files in my N900.

Moving out apt metadata

As some of you may know, in the N900, the root file system is stored in a OneNAND chip with 256M of space. Meanwhile /home and /home/user/MyDocs are in a eMMC in two different partitions: ~2GB (ext2) for /home and ~29GB (vfat) for /home/user/MyDocs.

The OneNAND is faster than the eMMC, and it’s intended to host only the Maemo main system, moving out the third party applications to the eMMC. Though, this new layout has brought new limitations, the more visible one is the /opt problem [2].

One of the debates about what left and what not in the OneNAND is the apt’s database and metadata. Moving out the apt’s database out from the OneNAND to the eMMC, in my personal opinion, is very risky: It will slow down the database processing (which is already slow given the size of the Fremantle repositories), and if the eMMC gets corrupted, the base system wouldn’t be upgreadable either, because apt couldn’t read its database. And that’s why I’m against the proposal.

Nevertheless I’m aware that the apt’s metadata and database could be huge, consuming much of the precious OpenNAND storing space. Just to mention it,  I’ve found myself, in my development cycles, moving out those files.

That’s why I cooked this script:

WARNING: this script is not official. You’re at your own if you run it: no promises, no guaranties.

shinning new HAM

A new version HAM will hit the streets soon, and we, the HAM team, are very proud of all the effort done.

There have been 178 commits since the first public release in the HAM repository, all of them affording user experience and trying to cover several corner cases on the SSU realm, specially dealing with reduced disk space in the OneNAND.

New section view in HAM
New section view in HAM

There are several new features and some eye candy:

  1. The section view has been improved greatly GtkIconView instead of the old buttons grid.
  2. Several user interaction (work flows and dialogs appearance) optimizations.
  3. Keep the cursor position in the package lists among operations.
  4. Add live search support, dropping the old search dialog.
  5. Avoid the update icon blink when the screen is blank, saving power
  6. maemo-confirm-text can show the package name who launched it.
  7. Minor fixes in logic strings and text display.
  8. Speed up the HAM launching loading the back-end using a lazy strategy.
  9. Speed up the package list processing in the back-end, so the package list are shown more quickly in the UI.

For the packagers there are also some bits:

  1. Adapt the .install files in order to interact with the packaged catalogs.
  2. Initial support for OVI store packages.
  3. Add a dbus function to search packages so other applications can interact with HAM.

And for the SSU, specially handling the reduced space disk in the root file system:

  1. Use always the eMMC for downloaded packages, avoiding the rootfs even as fallback.
  2. Stop as much process as possible when going into the SSU (stop prestarted apps, camera-ui, browser, rtcom-messaging-ui, alarmd, etc.) in order to reduce the double mappings of large files.
  3. Go into rescue mode if the SSU fails and change its looks to a less scary one.
  4. Sync the disk before fetching it status, moving the operation to the back-end.
  5. Because the documentation use a lot of disk space, we hack a way to get rid of it during the SSU.
  6. Use the higher disk compression during the SSU

Special thanks to Lokesh, David Kedves, Mario, Marius, Gabriel,  and all whom patient had helped us to make HAM a better piece of software to Fremantle users.

Embedded Linux Conference Europe 2009

A couple days ago Juanjo asked me if I wanted to attend the Embedded Linux Conference at Grenoble, France, sponsored by the CE Linux forum and I usually don’t say “no” to travel. So one day after I unpacked from Barcelona, I packed again.

One of the bad sides of living in A Coruña is the fly connections needed to go to anywhere. This time it was A Coruña – Madrid – Lyon (St Exupéry Airport) – Grenoble. Even though I found entertained and challenging all these heterogeneous connections.

In the registration area surprisingly I came across with Rob Taylor and Mark Doffman, from Codethink. Later on I saw also David Neary and Christian Schaller around.

The opening key talk was in charge of Jon Masters, and was about “Porting Linux” to other hardware platforms, where he just highlight some hints and landmarks in the porting process, such as run the vendor tests in the board, port the u-boot, read the hardware erratas (which are more insightful than the rest of the documentation); read the linux kernel mailing lists; use the flattened device tree to specify the device’s addresses (there’s no BIOS neither ACPI in embedded system); gave some recommendations using cscope; and finally insisted in not to take the x86 architecture implementation as references, because is too dirty, he rather recommended use the score arch (“x86 wouldn’t be designed today”). At the end he strongly advised about reading the development-process under the kernel documentation.

The next talk I attended was “Use of the Fast IRQ (FIQ) in ARM-Linux” by Allesandro Rubini. The FIQ is an interrupt request with a higher priority and can be handled while another IRQ. Allesandro use them as near-real-time signal processing under a non-real-time linux kernel. In this talk he showed his project, which hasn’t been accepted in mainstream, because is too task specific.

Then I stayed in the talk “Constrained Power Management” by Patrick Bellasi where he described multiple-policy power management optimization. Patrick distinguish two PM policies: device specific and system-wide. So he propose a coordinator entity among the local policies, and this coordinator uses some kind of linear programming optimization. Cool research stuff.

My objective for the conference was twofold: to learn about embedded linux distributions build systems, and to come aware of the community opinions about Android. So I’d the intention to attend the Matt Porter’s talk, nevertheless Masters recommended the PTXdist one, and I bought it: failed! The Porter’s talk won the “best talk” conference’s award.

PTXdist is just another embeddable-linux-distribution builder, based on Kconfig to “cook” your distro and in makefiles (GAR style) to build the packages and express their dependencies. An interesting feature is the fixup to avoid path hard-coding in libraries lookups.

Afterward I assisted to Nina Wilner’s talk about “Porting Android to Power Architecture”. She’s technology chief at IBM for the revamped PowerPC platform. Sadly she just make advertising for Mentor Graphics, the guys who employ Matt Porter and actually done the PowerPC port of Linux to Android. A couple interesting insights is that even though Google insist that Android is multi-platform it’s full of ARMisms, and porting its Bionic C Library to other architectures painfully. Nevertheless she stated that Android could make, in the embedded stage, what Linux made for Unix in the servers: do all over again and do it right.

Then I backed to the hardcore topics with “Analyzing Kernel Function Execution with ftrace” by Tom Bird. He’s also one the organizers of the conference. ftrace is the first generic tracing system to get mainlined. In this talk Tom explained his adventures to measure the duration of each kernel’s function at boot. With ftrace you can execute logging functions at every filtered function call. Meanwhile the community is expecting the port of dtrace to Linux.

In the afternoon Marcin Juszkiewicz talked about “Hacking with OpenEmbedded”. It was about different use cases for OpenEmbedded beside the embedded distro building.

Finally, the BoFs of the conference. I stayed at first in the Buildroot, another
embedded-distro-building which is too similar to PTXdist. At the middle of it I ran away to the Android BoF which I catch at the conclusions. Again, Android doesn’t bring nothing new, nothing breakthrough, but a lot of questions and doubts, as its ties with Google, its GPL licensing avoidance efforts, and so on.

And the Small Business BoF, organized by Michael Opdenacker, the owner of the company Free Electrons. Most of the companies there were quite small, several just one-person companies. The hottest topics there were about the lawyers need, the time tracking and billing, the hiring process and local vs abroad clients.

At the night we’d the social event: a cocktail buffet at Restaurant du Téléphérique, with a great panoramic view of the city.

At the next and last day, the opening keynote was in charge of Philippe Gerum: “State of real-time Linux: Don’t stop until history follows”. I arrive late to the talk but as far as I understood, he talked about the advances in the Linux kernel in the Real Time arena. He put special attention to the project Xenomai, which bring hard real-time support in the GNU/Linux user-space.

I flipped a coin and decided to go to “The LLVM MIPS and ARM backends” but I was gladly surprised with the talks swapping to “Coccinelle: A program matching and transformation tool” by Nicolas Palix. I came aware of the powerful concept of semantic patch. The principal use case for it, is to detect the collateral effects of an API breakage, also to fix common programming mistakes. It has been used in the kernel finding tons of potential unseen bugs. Neat!

After a short coffee break I ran into the “Survey of Linux measurement and diagnostics tools” by Frank Rowand. He shown a quick survey of several software tools for performance measurement such as smem (quite interesting); oprofile (quote: “sampling tools are not that good” also is turning obsolete); systemtap (measure the processor use in a non-intrusive way); time (the old & honest); perf (here Frank talked about the interesting problem of cache misses); bootchart; the kernel function trace; the LLTng, Timechart, an finally the famous ftrace.

Meanwhile the lunch time was getting arranged, a showcase took place in a room, where a couple projects were shown. The most impressive IMHO was the Nsec Linux system boot by Montavista. There was also Codethink with a all-microbloggers-on-one application; an LZO compression algorithm for the kernel; a demo of Android in PowerPC, etc.

In the second part of the second day, Gilad Ben-Yossef, from Codefidence, talked about “The good, the bad and ugly: on threads, processes and co-processes”, where he probed that in the Linux realm, threads and processes have no performance differences. In theory the big difference between a process and a thread is that the first owns a memory space and the second share it, so the context switching among process should be more expensive that in threads. So he decided to do some measurements with a modified version of lat_ctx, and surprise! no appreciable differences were shown. Thus, his conclusion, is that the reason why people prefer use threads instead of process is because the API. The mental model offered by the threads is more appeal to the common programmer than the process model, so Gilad decided to create a wrapper library to implement process API in terms of the threads API called coproc.

“A computer is a state machine. Threads are for people who can’t program state machines” — Alan Cox

The last talk I assisted was “Technical features and components of open source build systems” by Alex de Vries from Wind River Systems. It tried to bring a survey of all the requirements of a “perfect” embedded-distro-builder and then a pseudo BoF was raised with the question why we don’t have already one? There are tons of these system on the wild, but every has a very specific and reduced set of features. There was no conclusions but at least the seed was planted.

Finally, the closing keynote was carried on by Tom Bird and Klaas van Gend, in a mixed talk about the purpose of the CE Linux forums its goals and achievements with a contest of the butterfly effect. It was fun.

The conference closed with a round of drinks. I got a nice Chinese beer.

GIT quick notes

I want to work on a new plug-in inside of gst-plugins-bad. But also I want to expose my development to a personal GIT repository, so my friends could fetch my changes.

As Linus Torvalds explained once keeping a nice linear regression set of patches above an upstream development implies the use of git-rebase, nevertheless that also implies that I will have to force my pushes and my friends will also have trouble keeping their repositories in sync with mine.

So this is a kind of compromise between be nice with the people who pull your changes, or ease your daily work.

libgoo & gst-goo

Back in 2007 I started to work integrating OpenMAX IL components into the GStreamer platform.

OpenMAX is a set of programming interfaces, in C language, for portable multimedia processing. Specifically the Integration Layer (IL) defines the interface to communicate with multimedia codecs implemented by hardware or software.

Texas Instrument started to work on an implementation of the OpenMAX IL for their DSP accelerated codecs for OMAP platform.

A quick and rough view of the software architecture implemented to achieve this processing is more or less exposed in the next diagram:

| OpenMAX IL          |
| libdspbridge        |
| Kernel (DSP Bridge) |

The DSP Bridge driver is a Linux Kernel device driver designed to supply a direct link between the GPP program and the assigned DSP node. Basically the features offered by the driver are:

  • Messaging: Ability to exchange fixed size control messages with DSP
  • Dynamic memory management: Ability to dynamically map files to DSP address space
  • Dynamic loading: Ability to dynamically load new nodes on DSP at run time
  • Power Management: Static and dynamic power management for DSP

The libdspbridge is part of the user-space utilities of the DSP bridge, which purpose is to provide a simple programming interface to the GPP  programs for the driver services.

In the DSP side, using the C/C++ compiler for the C64x+ and the libraries contained in the user-space utilities, it is possible to compile a DSP program  and package it as a DSP node, ready to be controlled by the DSP bridge driver. But right now TI provides a set of out-of-the-box DSP multimedia codecs for non-commercial purposes. These nodes are contained in the tiopenmax package.

So, as I said before, my job was to wrap up the OpenMAX IL components delivered by TI as a GStreamer plug-in. In that way a lot of available multimedia consumers could use the hardware accelerated codecs. But also, our team did the test of the delivered OpenMAX components.

After trying several approaches we came to the conclusion that we need a new layer of software which will provide us

  • Facilitate a great testing coverage of the components without the burden of the upper framework (GStreamer in this case).
  • Improve the code reuse.
  • Use an object oriented programming through GObject.
  • Facilitate the bug’s workaround for each component and maintenance of those workarounds.
  • A playground for experimenting with features such as (OpenMAX specific) tunneling and the (TI specific) DSP Audio Software Framework (DASF).

For those reasons we started to develop an intermediate layer called GOO (GObject OpenMAX).

| GStreamer / gst-goo |
| libgoo              |
| OpenMAX             |

libgoo is a C language library that wraps OpenMAX using GObject. The follow diagram shows part of its class hierarchy.

                           | GooComponent |
+---------------+ +---------------+ +---------------+ +---------------+
| GooTiAudioEnc | | GooTiAudioDec | | GooTiVideoDec | | GooTiVideoEnc |
+---------------+ +---------------+ +---------------+ +---------------+
        |                 |                 |                 |
 +-------------+   +-------------+  +---------------+ +---------------+
 | GooTiAACEnc |   | GooTiAACDec |  | GooTiMpeg4Dec | | GooTiMpeg4Enc |
 +-------------+   +-------------+  +---------------+ +---------------+

At the top there is GooComponent which represents any OpenMAX component. If the OMX IL implementation is neat and clean, there shouldn’t need to add subclasses underneath it, just parametrize it, and should be ready to use as any other OMX IL component. But reality, as usual, is quite different: Every implementation is different from each other; and to make it worst, each component in a same implementation might behave differently, and that was the case of the TI implementation.

Finally, over libgoo there is gst-goo, the set of GStreamer elements which use the libgoo components. GstGoo also sketched some proof of concepts such as ghost buffers (to be used with the OpenMAX interop profile), and dasfsink and dasfsrc (TI specific).

In those days, before I move to the GStreamer team, an old fellow, Felipe Contreras, worked on gomx, which is the precedent of libgoo, before he got an opportunity in Nokia and started to code on GstOpenMAX. An interesting issue at this point is that Felipec is pushing boldly for a new set of GStreamer elements which ditched OpenMAX and talks directly to the kernel’s DSP bridge: gst-dsp.

What’s the future of libgoo and GstGoo? I couldn’t say. Since I moved to Igalia, I left its development. I’ve heard about a couple companies showed some kind of interest on it, sadly, the current developers are very constrained by the TI workload.