Speex encoder on n800′s DSP

I’ve been wanting to run things on OMAP‘s DSP processor since the day I tested an OMAP1510 development board some years ago. Finally after a Proof of concept G.711 dsptask mail by Simon Pickering I decided to cut’n'paste that and try.

I knew the Speex had already been ported to the DSP (TMS320C55) used by OMAP1 (770) and OMAP2 (n800) so I started porting it to the DSP Gateway to be able to use it in my n800.

The DSP Gateway’s DSP tasks are seen as /dev/dsptask/<taskname> devices on ARM side and are interacted with read, write, and ioctl calls. Very linux stylish and convenient in my opinion. On the DSP code one struct defines callbacks for these calls. The code overhead on DSP side is some tens of lines.

Speex has speex_alloc functions that can be overwritten if the default memory allocation is not suitable. In the existing DSP port these were overwritten with functions using preallocated global char arrays that are used for all allocations, freeing is not possible. The DSP char is 16 bits as is int. The long is 32 bits and a pointer is 23 bits. Long long is 40 bits. I had some problems with calculating with pointers (casting a pointer to long didn’t produce valid looking value) in the existing implementation so I rewrote the allocation functions to use arrays and indexes. Also the existing implementation printed pointer values as %x which seemed to print completely different values than %p. I did use dbg() however, not fprintf.

The dbg() prints will be shown in dmesg or syslog on the ARM side if the kernel is compiled with mbox debug. The n800 stock kernel is not, but it’s almost trivial to compile a kernel of your own. My kernel with mbox debugs and built-in ext3 is here.

Other than the allocation functions there was not much to port, couple of functions calling the speex’ init and encode functions. I did have an odd problem though: the DSP seemed to jam after some tens of seconds and the DSP kernel was rebooted. After I added poll_disable(task) in my encoding callback function, the jamming was gone. The function will disable the polling for 10 seconds. Afaik, that should be called only if the completion of the function takes more that 10 seconds, which it doesn’t.

My speex patch against the git head is available, if somebody wants to test it. There can be some weirdness as this is my first test with the DSP stuff and I don’t even know how to use the git ;)

If my measurements are correct it takes roughly 40 ms to encode one 20 ms frame without compiler optimizations. With -o3 it takes a bit over 20 ms. The speex is meant to be portable and has a header defining some math functions. The functions are ported to different CPUs like ARMv5 and Blackfin. Maybe some DSP guru quickly ports those to the TMS320C55 too? :)

I think the best place for DSP information for the tablets is in maemo.org wiki as I hope it will be kept up to date with the latest projects and tweaks. One thing to be added there would be a note about the skeleton page. I used the Active Block Receiving and Active Block Sending.

Chinook look’n'feel

The Chinook desktop with Plankton theme looks quite ok. It has some transparency as you can see from the desktop screenshot.

It seems to work decently although is has some minor and some major issues. They are probably solvable but at least didn’t work out of the box for me. For upgrading your application to match the Chinook’s APIs it’s stable enough, imo. Although I’m not sure which new APIs the Chinook alpha SDK includes, in addition to the new Hildon Desktop.

Chinook desktop

Chinook desktop

The Navigator application menu has a new big look. I’m sure some people will love it and some hate it, as usual. The menu behaviour seems a bit odd, like it remembers my last position in the menu when I reopen it, but is buggy.

Some of the old apps work, some not. I could get screen shots with my screen grabber, I could play OGGs with kilikali but although evince started up, it just jammed there. Mirage didn’t even start. And I couldn’t find File Manager from anywhere. Opera works OK when started from the application menu but the Hildon Desktop crashes when I try to open the Browser menu from Navigator. The most important app, osso-xterm, luckily works :)

Connectivity (wlan, bt, usbnet) seems to work.

Power saving, on the other hand, does not. Or at least for some reason the battery didn’t last even for a day when it lasts easily several days on the latest official release. I might have had the usbnet running though which can affect the situation.

Chinook on mmc

I tried Sardine long time ago on my n800 and didn’t get it running. Now Maemo 4.0 Chinook alpha SDK is released and I decided to try again. I want to have a working n800 always with me, so I put the Chinook on the second partition of external mmc (first one is still a normal vfat for OGGs etc).

Mirroring the rootfs

I started by creating a new rootfs on mmc based on my current flash rootfs. I roughly followed the info in HowToBootRootFSFromMMC in Maemo wiki.

I installed wget, downloaded and extracted gnu tar and used it to create a copy to mmc.


apt-get install wget
wget http://repository.maemo.org/pool/maemo3.2/free/binary/tar_1.14-2.1osso_armel.deb
dpkg -x tar_1.14-2.1osso_armel.deb /root/tar
mkdir /mnt/dev-rootfs/
mount /dev/mmcblk1p2 dev-rootfs/
mount -t jffs2 /dev/mtdblock4 /mnt/rootfs/
/root/tar/bin/tar cf - -C /mnt/rootfs/ . | /root/tar/bin/tar xvf - -C /mnt/dev-rootfs/

Upgrading to Chinook

Next thing was to upgrade the mmc rootfs to Sardine. This time I followed SardineGettingStarted in Maemo wiki.

I chrooted to new rootfs since upgrading a running rootfs would be next to impossible:

chroot /mnt/dev-rootfs/ /bin/sh
mount -t proc proc /proc
mount -t sysfs sysfs /sys/

First I upgraded my current stuff. I had some problems with fmradio package, so I just removed it:

apt-get remove fmradio
apt-get update
apt-get upgrade

I had to export osso-af-startup version 1.46-2 from svn, compile and install it manually because the version in Sardine repo had a dependency to non-existent osso-product-info package. It’s downloadable from here.

I added the Sardine repo to my sources.list:

#maemo:name Sardine
deb http://repository.maemo.org/sardine unstable main non-free

Then I upgraded to Sardine nicely with apt-get (dbus tried to install /var/run directory conflicting with ssh..):

apt-get update
apt-get install hildon-application-framework
apt-get upgrade
dpkg --force-overwrite -i /var/cache/apt/archives/dbus_1.0.2-0osso10_armel.deb

The current Sardine repo seems still to have the same issue with maemo-launcher (see bug 952) that failed my first test with Sardine, but this time it’s already fixed in svn. So I exported maemo-launcher version 0.23-1 from svn, compiled and installed (downloadable from here). I installed the new missing dependencies with apt-get -f install.

Clean up and exit:

umount /proc/
umount /sys/
exit

Installing bootmenu

Bootmenu is a must to conveniently choose which rootfs to boot.

Installation is pretty straightforward:

cd /root
wget http://fanoush.wz.cz/maemo/initfs_flasher.tgz
tar zxf initfs_flasher.tgz
cd initfs_flasher
./initfs_flash

Before the flashing part, I created a bootmenu.conf to include my chinook rootfs and my third rootfs. The default bootmenu is normally sufficient.

Reboot.

Booting to Chinook

I had trouble getting the Chinook to boot up. I got the Nokia logo and then a reboot. I booted to my flash rootfs, chrooted to mmc and installed syslog. Then I rebooted to mmc and then back to flash rootfs and examined the /var/log/syslog on mmc. It revealed the maemo-launcher bug.

Lesson learned again: syslog is a must to have in n800 for debugging different issues.

Now I got the Chinook booting, without a theme though. After I said twice no to “Restore backup from mmc?” question and cancelled the phone wizard, I got an ugly desktop without theme. Selecting the Plankton theme fixed this issue.

Now I have working Chinook with my WLAN APs configured and my extra apps installed. Kilikali still plays my OGGs without problems :)