Month: January 2010

gstjpegparser

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, last.fm). 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!

http://gitorious.org/vjaquez-misc/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: move-apt-dirs.sh

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