Ogg-support 0.8: Diablo

I finally compiled ogg-support for Diablo too. It’s available through the maemo downloads page.

I don’t know why the Chinook version didn’t work in Diablo any more. And I didn’t really want to start debugging why the Maemo’s mime libraries and the closed source Metalayer Crawler don’t want to work with the mimetypes copied from a desktop system. So, now there’s only one mimetype: audio/x-vorbis and no support for speex or theora anymore. On the good side, e.g. File Manager can now start OGGs to Media Player.

New feature is a Control Panel plugin to ignore the OGGs from the Maps application. After installing ogg-support wait several minutes for the Metalayer Crawler to finish and then start the CP plugin. Metalayer Crawler seems to be much much slower if you have the Media Player open while it indexes the files.

Ogg-support 0.7: Canola interoperability

Light Media Scanner now uses libivorbis (Tremor) instead of floating point libvorbis. Ogg-support now depends on newer build of libivorbis that exports the symbols needed by LMS.

There’s now ogg-support-lightmediascanner meta package which depends on lightmediascanner0-ogg for easier installation with the Application Manager.

Unfortunately all other issues with ogg-support still remain.

Ogg-support: Issues

The ogg-support is listed as the The Pearl for OS2008, thanks! :)

Even though the ogg-support has got nice ratings in the download page, it doesn’t work perfectly on the OS2008. Most of the issues has some sort of workaround so I decided to make a summary post of them.

Ogg-support breaks VOIP calls

Ogg-support adds Speex voice codec to the system and it seems that the VOIP client advertises it as the first choice. If both parties have it installed, it’s selected. But. The VOIP engine (or whatever) doesn’t know or just refuses to use Speex, so the VOIP stream is not actually sent, properly at least.

If you delete the Speex’ GStreamer plugin, the calls seems to work nicely.

Bug report (#2811).

All Oggs from Map are listed in Media Player

The Metalayer Crawler adds all known media files to the Media Player’s Library. With ogg-support also Ogg files are recognized and added to the Library. Problem is that the Map application includes almost 2000 Oggs with N810 so they are added to the Library too.

A workaround is mentioned in the ogg-support’s help forum. It requires editing the SQL database after the files are added to the Library.

Bug report (#2772).

File Manager doesn’t launch Media Player for Oggs

I had to modify the mime type XML a bit to get File Manager to recognize videos and audios in Ogg container separately instead of just showing all *.ogg files as e.g. audio/x-vorbis. To be specific I had to remove the *.ogg pattern from the XML file.

It seems that the hildon_mime_open_file() in libhildonmime doesn’t launch the file without the *.ogg pattern tag in XML.

No workaround for this one.

Bug report (#2521).

PS. Many problems are reported in the Internet Tablet Talk’s forums. I don’t follow those frequently so please notify me in the garage’s forums about possible bugs, issues or workarounds. I do get a instant mail notification about those. Thanks.

Ogg-support 0.4: Media Player

I added initial support for the built-in Media Player. It’s untrivial to get everything working properly as the FileManager, the Metalayer Crawler, and the Media Player are all close source applications and their behaviour is not really documented anywhere.

The change log:

  • Added OGG support for the built-in media player.
  • Updated ogg related mime types from freedesktop.org.xml (excluding *.ogg patterns).
  • Added icons for the new mime types.
  • Removed dependency to floating point vorbis library.

Known issues:

  • The FM doesn’t now how to start the new mime types.
  • The Metalayer Crawler doesn’t fill in the meta data (artist etc.) for the ogg files.
  • I removed the *.ogg patterns from the mime file because with it neither the FM nor the Crawler checked the real mime type for files but just put the first mime type with *.ogg pattern.

The Crawler did fill in the artist etc. for my ogg files at one point, but I don’t know why. If you have any hints for these issues, I’m all ears :)

PS. The MP now plays oggs with Theora video and Vorbis audio too :)

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 :)

Ogg-support 0.2: Speex

The 0.2 release includes dependency to the Speex (libspeex1 and the corresponding gst plugin in gstreamer0.10-plugins-good-kulve). The Speex is compiled from SVN trunk.

I made some light (just looked the numbers, no playback) performance tests. The two tables below show how much time in seconds it took to encode a 60 second audio clip (8000Hz, mono, 16bit). The first column shows the complexity used (scale is 0-10) and the rest of the columns show the encoding time with different qualities (0-10).

no VBR, no DTX, no VAD:

c/q      1       2       3       5       7
0       12       8      10      14      11
1       12       9      10      15      11
2       13       8      12      16      16
3       13      10      15      22      19
4       13      10      16      23      20

VBR, DTX, VAD:

c/q      1       2       3       5       7
0       10      10      11      14      16
1        9      10      13      14      16
2       10      12      13      15      18
3       11      13      15      19      22
4       11      13      17      20      24

The next table shows the difference between fixed point and floating point versions.

c        fixed     float
0        11        17
1        11        18
2        13        20
3        19        29

So, use the fixed point Speex API, if possible (the gst doesn’t use it). If using the floating point API, the libspeex will make the conversion.

For VoIP a good quality setting could be quality 7, complexity 2 and VBR, VAD, and DTX on.

Ogg support for n800

The Internet Tablets don’t support Ogg natively, so there has been some open source projects to add it. I made yet another one.

Features:

  • Adds application/ogg and audio/x-ogg mime types
  • Add GnomeVFS mime type icons for above
  • Depends on ogg, vorbis and theora libs and on the corresponding GStreamer plugins

See project page, home page or install it (conflicts with kilikali-codecs-meta).

For an open source player, see kilikali.