The lines are getting longer and thicker day by day. And now an N950 of a friend of mine started to do the same thing. I wonder if this is happening to all of them?

N9 is the only viable option for me with its own pros and cons. Hopefully it won’t disappear too quickly from the shops..

3 1

I started to implement webupload and SSO plugins but I never got them to work. The biggest show stopper was lacking documentation for the SSO part. Finally Mika Suonpää pointed me to Share UI plugins and now, only a few days later, I have the first version of it working for n950 :)

For some reason I don’t get my icons visible, they are always shown as a red square. All hints about that are most welcome. As is testing and feedback of the plugin. The plugin settings are in Settings -> Applications -> Command-line Share, and from there you need to enable the plugin and set the command to be run. After that the sharing plugin is visible in the Gallery -> share.

The source code can be found here and the corresponding forum thread here.

4 1

The decoder code has changed completely. Where the old one used libvorbis and vorbisdec from the GStreamer base plugins, the new one uses libav (formerly FFmpeg) and gst-av from Felipe Contreras. The impact on performance should be significant because the vorbis decoder in libav is more efficient on the n900 than the libvorbis and Felipe’s gst-av also outperforms the vorbisdec.

Thanks to Felipe for doing all the hard work. I’ve just been updating the version numbers of the dependencies and tracking the bugzilla for the known issues and fixes :)

7 0

MeeGo doesn’t provide an SDK for the (ARM) platform. There’s an SDK for building Qt applications and there’s an QEMU for emulating the ARM device environment. For building the lower level components (Qt itself, GStreamer, etc) you are expected to use OBS. OBS is a very good build infrastructure tool, especially as you can link your own OBS to upstream OBS instances like MeeGo or OpenSUSE and have your OBS build only your own components or modified upstream components.

But OBS is a bit overkill when you are developing your own component that you don’t want to be a part of anything bigger yet. The OBS client side tool, osc, allows you to build components locally in a chroot but still you need an OBS account and those aren’t automatically available for everyone, not even in the community OBS.

I took the chroot created by osc build and modified it a bit with the help from stskeeps @ #meego-arm. The produced chroot is capable of building ARMv7 hard-float binaries without OBS or OBS account. It includes a minimal set of dependencies to make it smaller for easy download (it’s still 162MB), and the project specific dependencies can be installed normally with zypper from the standard MeeGo repositories.

The benefit from using a chroot over a QEMU image is the installed speed tools; many of the components taking time during a build are actually x86 binaries. These include e.g. bash, compilers and bzip2. Running these as emulated ARM binaries (or natively on an ARM hardware) would be much much slower.

I’ve used this approach with my own Qt + GStreamer project and it has been working well but that’s only a small use case so there can be all kinds of issues still. I use the same account inside the chroot and outside and bind mount my $HOME to the chroot so I can build project under my $HOME.

Current known issues:

• Zypper doesn’t find noarch packages (this is an upstream bug, not related to my chroot).
• Tested only on Debian Squeeze. At some point there was a linker issue on Ubuntu and I don’t know if that still exists.
• My instructions mention libqt4-devel although the package name is libqt-devel.

If you want to try it out, it’s available via BitTorrent at http://tuomas.kulve.fi/tmp/torrent/ (temporary location). After extracting the tarball, see the readme file in the root directory.

5 1

It has been working for me for several months without issues, although I’ve been sharing only medium size images over a decent connection. It might not succeed in sharing videos over GPRS.

For hints about the usage, see the previous post.

10 0

I pushed the first “proof-of-concept” quality implementation to the GIT a month ago. I’ve been using it with the Irssi script (in the scripts directory) to get http URLs with meta information to IRC. The Irssi script needs to be modified to match the directories and IRC servers in use and both the script and the sharing plugin are still missing most of the error checking and extra functionality. Nevertheless, they’ve worked for me for the past weeks.

For the sharing plugin I’ve given something like the following command line:


scp %s kulve@foo.bar.fi:~/photos_incoming/%s


There’s two times the %s as the local temporary file name doesn’t match the actual file name to be copied. And that assumes the SSH keys have been exchanged so that no passwords will be asked.

The Irssi script polls the incoming directory for new images. For each new file, it moves the file to public WWW tree, gets the meta information with exiftool and prints something like this to the specified IRC channel:


Title: Description [tags] (GPS coordinates) http://foo.bar.fi/~kulve/imagename.jpg


I modified the Irssi script a bit before pushing it to the GIT, so no guarantees it works. And that’s my first Irssi script ever, so it may do something odd ;)

There’s no debian packages yet as neither the script nor the plugin have been tested properly. Comments, testing and patches are welcome.

13 0

All tests were run on a preproduction n900 device that Nokia distributed at the Maemo Summit. The software is the Maemo5 41-10 release which was already installed in the device. I installed Ogg Support, gst-av, ffmpeg and OpenSSH. Otherwise the device is the default 41-10 release. WLAN connection was configured but not activated during the tests. A SIM card was in place only in the SIM idle test.

Before every test I charged the device, disconnected the charger once I noticed the green led, and rebooted the device. After the boot I started a simple script in the xterm. The script logged current time to a file, run “sync” command and slept 60 seconds after which it started the loop again.

Idle tests

I run two idle tests between the libvorbis and ffvorbis tests but I’ll introduce the idle results first.

First idle test was a generally idle device. I.e. it did have the default processes running but I didn’t start anything, except my logging script. During the test I did check a couple of times if the device was still on. The battery lasted for 93.8 hours.

According to Igor Stoppa, there’s a cellmo sw bug that makes current higher without a SIM card. Therefore I rerun the idle test with a SIM card inserted. During the test I received two phone calls which I hung up, I received two SMS messages and wrote one. At one point the notification led was blinking for 45 mins. The battery laster for 93.6 hours.

There’s probably a few hour error margin on those tests, so basically the battery lasted roughly a bit over 90 hours in both tests.

Powertop shows that after 60 seconds of showing the xterm with display blanked, the CPU is mostly in the highest C4 sleep state:

Ogg vs. MP3

Now that we know how long the device will last when idle we can move to the actual results.

I run two sets of tests. First one was with the Ogg Support 1.0.5 from Extras and the second one with Felipe’s gst-av (2009-09-25) which is using vorbis decoder from FFmpeg (2009-09-07). I repeated both tests three times, running every other test with MP3 and every other with Ogg.

After restarting the device with a fully charged battery I started the logging script in the xterm, started the File Manager and clicked on the MP3 or Ogg file which then started playing that single file in a loop in the Media Player. Both files were encoded with variable bitrate 192kbps settings. Volume of the device was set to minimum and no headphones were connected.

This is what powertop shows while playing MP3 in Media Player compared to libvorbis:

Clearly while using libvorbis the CPU spents more time in lower sleep state and running with higher frequency. The following graph shows how this affects the battery. The battery lasts around 18 hours while playing MP3 but only around 11 hours while playing Ogg.

Next numbers are with ffvorbis instead of libvorbis. Powertop shows that while using ffvorbis the time spent in different sleep states matches quite closely to the ones of MP3 usage:

The similarity of the powertop numbers can be seen in the battery duration as well:

The average battery duration while using ffvorbis was slightly better than while using MP3 but probably well within the error margins. So basically they are equal when battery duration is concerned.

It’s interesting to see how the situation changes in a year, will Nokia make better optimizations to their MP3 decoder than the community to the FFmpeg. These tests were run in a preproduction device with a pre-sales software. I’m sure the overall power management of the device will get (even?) better in the future software releases.

Addition (2009-11-17):

When using the speakers the n900 runs some “speaker protection algorithms” that take extra power. I repeated the ffvorbis test case with Nokia’s headset and here are the results:

On the average the battery duration improved a bit over three hours.

Addition (2009-11-25):

I run the same tests (Ogg Support 1.0.5, no headset) for Flac:

n900 with a pre-sales w41-10 software can run Flac roughly 1.5 hours longer than MP3.

46 0

Bugs

There’s a product for Ogg Support at the Maemo Extras Bugzilla. I’ve added the major issues there but do report any other issues you find.

Tags

Media Player and File Manager depend heavily on the open source Tracker for the meta data. Tracker has different meta data extractors for different mime types. GStreamer extractor is used by default for all audio/* and video/* mime types. The gstreamer extractor uses tagreadbin for getting the meta data from the media files.

For better efficiency tagreadbin uses only parsers for getting the meta data. Decoders may need e.g. separate DSP hardware, so using decoders for getting the meta data could be a very slow and heavy process.

Unfortunately Vorbis and Flac tags are not in the container and need a decoder for parsing them. Tracker provides a separate extractor for Vorbis that’s now packaged separately for Maemo by Ivan Frade. That’s not “product quality” and shouldn’t be used, so a proper solution will replace that one. The work for getting a tag parser for Vorbis and Flac to be used with tagreadbin has already been started. Hopefully the patch will be attached to the Gnome bugzilla at some point.

Gstreamer’s playbin(2) element reports tags while playing the media file and this already works with Vorbis and Flac. MP and FM need to know the meta data before they start to play the file but e.g. the Media Widget on the Desktop seems to get the tags from the playbin2 as it shows the tags for Flac as well.

Performance

The Vorbis decoder from xiph.org isn’t as fast as the FFmpeg’s Vorbis decoder on the n900.

There weren’t any GStreamer plugins for the FFmpeg’s Vorbis decoder until Felipe implemented one. The gst-av is still missing some features that need to be implemented before it can be taken into use, mainly tags and streaming.

If you are interested in the topic, I’m sure Felipe would be more than happy to apply patches :)

I’ll report numbers about performance comparisons between MP3 and Ogg later.

14 0

The support for Vorbis audio is good: tags work, File Manager shows them too and knows how to launch Vorbis files in Media Player, etc. Flacs are missing tags but no magic is needed for that, just a new GStreamer element. Theora support is also included. I haven’t tested it much but at least the basic features seem to work.

I’ll tell more about the details at the Maemo Summit.

40 2

Hopefully everything will be easier to get working with the N900 since at least the closed source Metalayer Crawler is replaced with open source Tracker.

I would like to hear if there’s anything special people would like to get with ogg-support. Support for oggs in the built-in media player with tags is of course the first goal but is there something else that is a must? Theora? Flac?

Thanks.

30 0

The examples on the book can be downloaded from http://www.opengles-book.com/. Those are meant to be compiled with Microsoft Visual Studio.

I made a small patch that adds initial support for Linux/X11. It doesn’t support texture loading (because I misplaced my png loader somewhere), the WinCreate() is copypaste code I don’t fully understand and the WinLoop() is missing some functionality. But at least the Chapter 1 Hello Triangle compiles and runs in Fremantle on Beagle board :)

Compile and install the libes in a normal autotools manner. Then you can compile the examples by exporting the PKG_CONFIG_PATH and running gcc:


gcc `pkg-config libes --cflags --libs` Hello_Triangle.c -o Hello_Triangle


As usual, patches are welcome :)

13 0

The Kaze project for n8x0 devices was updated to use the generic-2 branch as well. There are no built images provided, but ALIP is relatively easy to compile if one is already familiar with Scratchbox. The ALIP rootfs works with the Maemo kernel and initfs and it can be booted nicely from an MMC/SD card, so no need to destroy the Maemo from the device just to test ALIP.

ALIP requires newer SB components (and specific toolchains) but the newer SB components should work just fine with Maemo targets and Maemo toolchains. Or the newer SB can be installed in a different directory from tarballs and used concurrently with the Maemo SB.

Follow the From scratch instructions but replace alip-project with kaze-project and don’t pass the -cbeagleboard. You should pass -c multimedia to include 3rd party provided (by me actually) gst-ffmpeg to the build.

If you want to include WebKit engine and Midori UI to it, add “midori” to the components file.

Unfortunately the X driver for OMAPs (xf86-video-omapfb) in the stable branch in omap-repository has a bug concerning n8x0 devices and you should use master branch of it if you want to test video playback. The easiest way to switch using master branch for this component is to clone the n8x0 configuration repository and switch the branch before running the matrix install.


git clone git://linux.onarm.com/git/n8x0/config/n8x0.git
vi n8x0/suite/n8x0-recommended
# Add the branch: Component("xf86-video-omapfb", branch="master")
matrix install -c multimedia


After the install you should include the binary DSP tasks from the device (they are proprietary and cannot be distributed). Use the helper script (get_nokia_binaries.sh) in src/platform-n8x0 that fetches them from the device over ssh and reinstall the component before creating the rootfs image:


matrix install-only -c multimedia platform-n8x0


Lots of things are still broken:

• Power button tries to suspend, which fails and does nothing.
• WLAN encryption keys are not stored succesfully.
• WPA doesn’t work (WEP and unencrypted do work).
• Midori should be started after networking.
• There’s no ssh client (but dbclient as it’s dropbear).
• Power management.
• Default XFCE theme doesn’t look cool.
• Etc.

But I believe that with some work Kaze on n8x0 will become decent enough for everyday use and will provide up to date components long after Nokia has dropped the n8x0 support.

If you have any questions, visit #alip @ freenode.

PS. If you want an open source media engine with D-Bus API checkout the Octopus. It’s a work in progress but handles basic audio and video playback on n8x0 just fine :)

10 0

I’ve also managed to get the tags (except for the album) to show up in Metalayer Crawler. But that code isn’t even in SVN yet.

Kilikali shows all the tags properly and based on the GStreamer debug prints the MLC also gets the album tag but for some reason doesn’t write it to ~/.meta_storage SQL db.

Too bad the MLC is closed source so I can’t debug further why it rejects the album tag.

16 0

I didn’t change the mimetypes though, so all *.ogg files are seen as audio files even though they may contain video streams as well. I quickly transcoded the Big Buck Bunny video to lower resolution ogg containing Theora video and vorbis audio. The Media Player was able to show it although I should have used even lower resolution (and lower audio bitrate).

Comments are welcome.

8 0

Kilikali development has moved to a GIT tree (branch generic-2) hosted by linux.onarm.com.

Although the UI got improved and the playback on n8×0 got fixes there are still some bigger task to be done. E.g. adding single files, adding directories recursively and skipping unknown media types. Integration with Light Media Scanner has also been discussed.

7 0

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.

15 0

All components (applications, libraries, etc) are in GIT repositories. The build tool is called Matrix. Matrix clones all components under one directory and compiles them with a single command. With another command you get JFFS2 image although that’s not as simple as it should be.

ARM would like to get all contributions directly to upstream instead of providing large code dumps and states that developers are encouraged to participate in discussion forums and developer community of respective components used on this site. That’s why there are no new mailing lists nor forums available for the platform. There is #matrixhelp (#matrix was taken) on irc.ipv6.oftc.net for Matrix related issues though. Developing the components is convenient if you are familiar with GIT. It’s easy to test if your patch works and send it to the upstream project.

One of the supported hardware platforms is n8×0 which is nice as it’s commonly available. The downside is the closed source nature of it. There are two projects, example-project and Kaze that has n8×0 configured as one target platform. Kaze has XFCE desktop instead of Matchbox desktop that the example-project uses.

Kaze boots but most features need still work. WLAN works without encryption but WEP and WPA encryptions need to be fixed. ALSA works with alsa plugins through the DSP but the closed source DSP tasks need to be copied to the build system. Kaze has normal X.Org instead of Xomap, so there’s no XV extension, only stubs.

In the test I compiled a very simple test code with different -mfpu and -mfloat-abi options, -O2 and -march=armv6 were given in all cases. The asm code is linked in the table. The code is a simple for loop which could be optimized to one round but based on the results it looks like the gcc didn’t do this kind of tricks.

Although you can ask the default options from the gcc I decided to test also without the options. The test was run on n810 and results are in the table below.

Looks like the default for -mfpu is vfp and the default for -mfloat-abi is soft.

There are three different values, one takes some seconds, one takes some tens of seconds and one takes some minutes.

This was expected as there are three different ways to do floating point math. In the slowest one the kernel emulates the fpu after cpu has run into undefined floating point opcode. This is extremely slow as there are a lot of context switches. A faster way to do the floating point math without the hardware is to let the gcc to compile the floating point math to the binary itself (and something in libgcc?). The fastest way is to use the VFP hardware.

6 0

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.

5 4

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.

9 0