Introduction

One of my purposes for this year was collaborate with the gst-dsp project. But the JPEG decoder was not enough, as there are other released socketnodes by TI which are not yet wrapped in gst-dsp, such as, in this case, the AAC decoder.

gst-dsp is a project with only video decoding use case in mind, and audio streams might not be optimally handled by it. The biggest concern was about the memory mapping of small buffers, which could consume more CPU rather than the direct decoding. Nevertheless I decided give it a try.

These last two weeks I devoted them to pull out the dspadec element and it seems to perform quite good without any significant modification in the gst-dsp core. You can find the submitted patches in the gst-dsp mailing list.

These patches are still in review process and perhaps they will not land on the repository, nevertheless, I also updated the marmita’s recipes in order to provide an installable image for the beagleboard, so anybody could test this new element.

• Root FS
• uImage

Among other candies, this marmita snapshot brings libsoup and the souphttpsrc GStreamer element, besides all the alsa stuff for the audio rendering. Also gdb hit into the tarball.

Enjoy it!

These bytes were brought to you thanks to Igalia, who sponsored this development.

By the way, a group of  igalians, including myself, will be tomorrow in Dublin for the Meego Conference 2010. I’ll be at the Igalia’s exhibition stand with a demo of the Pandaboard running Meego and -hopefully- rendering on-line multimedia through Grilo.

Finally, the last Friday the Pandaboard arrived to the office. Thanks to all the guy in TI who generously decided to give me one, specially to Jayabharath Goluguri and Rob Clark.

The next Saturday, Ryan Lortie and I came to the office to fool around with the new toy. Just one word: Impressive.

Ryan set up the Ubuntu Maverick Meerkat image for the Pandaboard. At the beginning we ran with a couple problems, but with the help of Ogra we couped  them. First lesson learnt:

The SD for Maverick must be, at least, a 4Gb card, not less.

Second lesson learnt:

The USB is unable the power the Pandaboard. Thou shall power the board with a normal 5V power supply.

Also we found that my monitor, a LG Flatron W2261VP, is not well handled by the PVR X driver, but still it’s usable under 640×480. Ryan filed a bug about this issue.

It was great start up experience. The next stage is play with syslink and DOMX. Anyway, I won’t use Ubuntu for it, my plan is go with the minimal-fs stuff.

In the DSP bridge realm, usually when the kernel module is loaded, it in turn loads the so called DSP base image, which is a file what encompass the DSP/BIOS kernel and the DSP/BIOS Bridge.

Usually, in a development cycle, you may want to test different base images, and removing and reloading the Linux bridgedriver module is not very practical. For this case, TI provides the cexec.out utility, which uses the bloated libdspbridge API, to load in runtime different DSP base images.

But we all know that cool boys use dsp_bridge instead of libdspbridge, which is much more clean, small and nice. And also we have a neat set of utilities called dsp-tools. Nevertheless a utility like cexec.out was missing, and because of that dsp-exec has born.

Last week, my patches were committed by FelipeC into the stage repository in github, and I’m enjoying them while I’m poking around in the audio decoding

Do you remember this comment? Well, I took the challenge, and it has been hard to accomplish.

When I started to play with the Beagleboard, my objective was to poke with the DSP accelerated codecs through OpenMAX and GStreamer. But soon I realized that it would be a hard task to achieve since the framework, developed by Texas Instrument, is in part proprietary (though free), and the another is open source, but it is not developed with an open source community in mind.

I still don’t know how to submit my slides into the FOSDEM website, so I’m linking them here by now:

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 too!

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

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: move-apt-dirs.sh

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