Linux – Tuomas Kulve

XBMC for Tegra with full HW acceleration

September 18, 2014tuomas

XBMC at UltraHD resolution. — XBMC running at UltraHD resolution on Jetson TK1.

Thanks to Markus Tavenrath there is finally a fully accelerated Kodi (previously known as XBMC) for Tegra K1 based devices like the Jetson TK1. Some of the Kodi patches are already upstreamed and the rest will be hopefully soon. Jetson supports X.Org very well and things like XRandR based TV refresh rate changes work perfectly.

I have a simple lab power supply (Mastech DF17132) and I made some quick power measurements with it. I did only guestimate the typical reading instead of making multiple tests and calculating the averages. So the numbers should be close to the truth but not scientifically accurate. I replaced the power supply that came with the Jetson with the lab power, so I have not included the consumption of the Jetson’s external power supply in the measurements.

The on-demand CPU frequency governor does not provide proper CPU clocks for smooth Kodi UI and video playback, so all the Kodi tests have been run with all four CPU cores forced on-line and with performance governor.

My USB hub, USB keyboard and USB mouse consume about 0.84W. The very noisy fan takes about 0.72W. That is about 1.5W that is included in the numbers below but maybe should not as everybody use different USB devices and nobody can use that fan in an HTPC setup.

In full screen video test cases the TV’s refresh rate has been changed to 24Hz and when the XBMC UI is visible, the refresh rate is 60Hz for 1080p TV and 30Hz for 2160p TV (HDMI 1.4 limitation).

1920×1080 Sony TV
Test case	Power consumption
Slim Login	3.36
XFCE desktop, idle, ondemand	3.36
XFCE desktop, idle, performance	3.72
Kodi main menu	5.40
Kodi full screen video 1080p24	5.16
Kodi full screen video 1080p60	6.00
Kodi full screen video 2160p24	5.40

In the table below, the resolution used for all the cases is Ultra HD or 2160p or 3840×2160. The term “4k” is misleading as people often really mean the Ultra HD and not for example 4096×2160.

3840×2160 LG TV
Test case	Power consumption
XFCE desktop, idle, ondemand	3.72
XFCE desktop, idle, performance	4.08
Kodi main menu	5.52
Kodi full screen video 1080p24 (max gpu clocks)	6.96
Kodi full screen video 2160p24 (max gpu clocks)	6.96

I think decoding 1080p24 with 5.16W (or 3.7W without USB peripherals and the fan) is pretty good! Add 2 watts and you get 2160p.

After watching different trailers over and over I definitely would like to see movies being produced at higher FPS rates and distributed at higher bitrates instead of bumping the resolution from Full HD to Ultra HD. That 1080p60 looked awesome.

The biggest complaint I have about the Jetson, is the fan. The noise is way too loud even for development use, not to mention using Jetson as an HTPC in the living room. There is some discussion about using passive coolers in the NVIDIA forums.

For installation instructions and other tips see the Installing Kodi wiki page.

Ubuntu on Ouya

March 24, 2014September 20, 2014tuomas

[Update 2014-09-20]: The latest patches from Markus for the Jetson TK1 work also for Tegra3!

I was testing Markus Tavenrath’s EGL branch of the XBMC on my Ouya and noticed that OMX_UseEGLImage segfaults on Debian but doesn’t on Ubuntu. The segfault happens inside the NVIDIA’s OMX binary, so there is not much to debug. And with Ubuntu 13.10 I had rendering issues. Then I tried Debian Jessie just to discover it is already using X.Org Video ABI 15.

So here is the summary of my discoveries:

Debian Wheezy: Segfault in OMX_UseEGLImage with XBMC.
Debian Jessie: X.Org Video ABI 15, no driver.
Ubuntu 12.04: Old.
Ubuntu 12.10: Old.
Ubuntu 13.04: No obvious issues.
Ubuntu 13.10: X.Org Video ABI 14, rendering problems.
Ubuntu 14.04: X.Org Video ABI 15, no driver.

I noticed that Totem has moved to GStreamer 1.0 so it does not use NVIDIA’s GStreamer plugins. I changed Parole to use nvxvimagesink instead of the de-facto xvimagesink and it works well. I’ve uploaded the binary to my tmp.

Pulseaudio seemed to cause slow playback and extra CPU consumption so I just removed it.

My instructions for creating Ubuntu Raring rootfs for Ouya can be found from github. Do leave a comment if there is anything broken with the instructions!

Steam on Debian Stable

December 1, 2013October 11, 2014tuomas

I like the idea of being able to play games on Linux, so the announcement of Steam for Linux was a big thing. Too bad Debian Stable has too old C-library for it. During the past year I’ve occasionally tried to get Steam running on Debian Stable (Wheezy) with usually little success. Currently I think installing Debian Testing (Jessie) to a chroot is the most easiest way. It is not as complicated as it may first sound.

One catch is that you need to be running the same version of NVIDIA’s drivers inside the chroot and outside of it so they need to be built.

On my gaming PC I use self-compiled kernel and the latest drivers from NVIDIA. On my media box in the living room I have some old integrated NVIDIA chip. Trine 2 runs nicely on my Gaming PC (GTX 760) and awfully on the integrated chip. I assume it’s about the chip and not about the different driver version (319.72 vs 331.20) and I doubt I’ll install the latest drivers just to verify that.

Update NVIDIA drivers from Jessie:
(Updated 11.06.2014)

Inside the chroot:
$ cd $HOME $ mkdir nvidia $ cd nvidia $ apt-get source nvidia-driver

And then outside the chroot:
$ cd $HOME/nvidia $Â cd nvidia-drv- $ dpkg-buildpackage -b $ cd .. $ sudo apt-get install -t wheezy-backports module-assistant $ sudo dpkg -i *deb

It’s not mandatory to use Debian packaged NVIDIA drivers. Just be sure to install the same NVIDIA driver package inside the chroot that you are running outside with the 32bit OpenGL libraries. You should skip installing the kernel module inside the chroot:

$ sudo sh NVIDIA-Linux-x86_64-331.20.run --no-precompiled-interface --no-runlevel-check --no-kernel-module --no-x-check --no-kernel-module-source --no-distro-scripts --no-nvidia-modprobe --accept-license

If you see “ERROR: Unable to create ‘(null)’ for copying (Bad address)” just hit OK several times. Also you may need to add /etc/ld.so.conf.d/nvidia.conf with “/emul/ia32-linux/usr/lib/” in it and run “sudo ldconfig” after adding it.

Create Jessie schroot

These instructions are adapted from https://wiki.debian.org/Schroot and assumes 64bit host Debian.

WARNING: removing schroot with “rm -rf” while it is active will delete your home directory as well! You should reboot and make sure there is nothing mounted inside the chroot before removing it.

Install schroot for chrooting and debootstrap for creating the Jessie root filesystem:

$ sudo apt-get install schroot debootstrap $ sudo mkdir -p /srv/chroot/jessie

Create the Jessie rootfs (the last parameter is optional for faster downloads):

$ sudo debootstrap --include sudo jessie /srv/chroot/jessie http://ftp.[your country domain here].debian.org/debian/ $ sudo mkdir /srv/chroot/jessie/run/shm $ sudo chmod 1777 /srv/chroot/jessie/run/shm

Configure Jessie schroot (note that you need to add your user account’s group name in there):

$ sudo vi /etc/schroot/schroot.conf

[jessie] description=Debian Jessie (testing) 64-bit directory=/srv/chroot/jessie type=directory groups=[your group name] root-groups=root aliases=default personality=linux preserve-environment=true

$ sudo vi /etc/schroot/default/fstab # Uncomment /run/shm

The /etc/group is shared between the chroot and the host Debian. Rest of the instructions assume your account belongs to the sudo group:

$ sudo adduser [your user name] sudo

Finishing the schroot

Schroot into Jessie and verify sudo:

$ schroot $ cat /etc/debian_version # Should say Jessie $ sudo -l # Should show that you can run ALL

Configure APT to use non-free packages and multiarch with i386:

$ sudo vi /etc/apt/sources.list # Append "non-free contrib" $ sudo dpkg --add-architecture i386 $ sudo apt-get update

Install Steam from Jessie and some dependencies:

$ export LC_ALL=C $ sudo apt-get install python xdg-utils less libvdpau-dev libalut0 pciutils lsb-release libopenal1:i386 libvorbisfile3:i386 libglu1-mesa:i386 build-essential libgl1-nvidia-glx:i386 libgl1-nvidia-glx:amd64 steam $ exit

The schroot is now ready and you can launch Steam directly from the host Debian:
(Updated 11.10.2014, See github issue for details)
schroot sudo /etc/init.d/dbus start steam

If you spot a mistake in the instructions do leave a comment below so I know to fix it.

Debian on Ouya: All Systems Go

September 12, 2013tuomas

I finally got all the major subsystems working and Debian is now usable on Ouya. I prefer Debian but Ubuntu should work similarly.

In the above screenshot I’m playing 1080p H264 while running glmark2-es, an OpenGL ES benchmark. And the CPUFreq ondemand governor doesn’t even raise the CPU frequency from the minimum as everything is properly accelerated. I do have to admit that the 1080p video isn’t running smoothly with the benchmark running at the same time.

A disclaimer before telling more: Trying this out might void the warranty and flashing anything to Ouya may easily brick it forever. So don’t try it, unless you are willing to buy a new one.

That said, the idea is not to touch Ouya’s Android at all. Kernel is booted from RAM and Debian from an SD card or USB stick.

The instructions for debootstrapping your own Debian Wheezy rootfs are described in the github repository and the needed binaries are in a temporary location that will probably change at some point.

WiFi is working as well but I’m not sure if the firmware binaries are redistributable, so you need to copy them from the Android rootfs after booting to Debian.

One of my main goals for this whole exercise is video encoding and I’m happy to say that H264 encoding from an USB webcam works nicely with hardware acceleration as well.

I’ve also noticed some issues:

Hciconfig doesn’t show BT devices, I didn’t debug much further.
Mpg123 seems to play but nothing is heard. Maybe it tries to pass MP3 onwards instead of PCM? GStreamer provides acceleration for MP3 and AAC though.
Video acceleration works only with GStreamer and nvxvimagesink. Mplayer can’t even use XV video output correctly.
Tegra3 supports only OpenGL ES 2.0 with EGL, so no full OpenGL with GLX.
Xrandr seems to be able to switch the resolution but after the switch there was window decoration corruption.

Despite the deficiencies I think Tegra3 is quite well supported in the X.Org world and many things work well with this 99$ device.

If you test my instructions, let me know how it goes and what you think about it! :)

Command-line sharing for Harmattan

January 12, 2012January 12, 2012tuomas

I use IRC and I want to be able to share photos there easily. For n900 I had implemented a sharing plugin and that worked nicely. When I got the n950 I of course wanted to do the same with that but it turned out to be a difficult task.

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.

Ogg-support 1.1.1: Performance

July 27, 2011tuomas

After almost two years there’s a new version of the Ogg Support in the Fremantle Extras.

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

MeeGo 1.2 ARMv7 chroot (beta)

July 9, 2011tuomas

I’ve always liked the Scratchbox approach to cross-compiling. Run ./configure && make and you have an ARM binary, no need to explicitly tell the configure we are cross-compiling nor fix the bad behaving build scripts.

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.

Pleco Phase01 completed

April 5, 2011tuomas

I started playing with microcontrollers in 2005 and, if not at the very start, at least very quickly I decided to aim to have some sort of remote controlled Linux device with controllable camera with digital wireless communication. Now, 6 years later, I have completed my first phase :)

Couple of photos of the earlier devices are shown in the project page.

After several planning iterations and code rewrites I ended up using Qt both on the remote controlled Gumstix and on the GUI controller. I decided that trying to optimize everything from the memory and CPU consumption to the network bandwidth just isn’t worth the time spent in implementing it. The most CPU intensive task is the video encoding to H263 and that’s done in the DSP. I’m running MeeGo on the Gumstix and it provides e.g. the GStreamer plugins for the DSP.

Using Qt framework with self made simple protocol over UDP I got the Phase01 code implemented quite quickly compared to my previous efforts. The protocol allows low priority packets (like periodic statistics and video stream) to be lost and guarantees the passing of high priority packets (control commands etc.). Also only the latest control command of each type is retransmitted, i.e. an old packet is not retransmitted if a new overriding command has already been given.

The controller GUI shows the states the slave sends, like motor speeds, WLAN signal strength, CPU load average and some protocol statistics like round trip time and the number of retransmissions.

Currently the motors are controlled using the a,s,d,w keys in 10% steps and the camera is controlled dragging the mouse left button pressed on top of the video window.

Here’s a video (direct link) of the Phase01. You need HTML5 video capable browser with Ogg Theora/Vorbis codecs.

Suspending the Workstation

March 27, 2011tuomas

I’ve always kept my computers up’n’running day and night although they are mostly idle during the time I sleep or labour at work.

I’m too lazy to shutdown the whole thing few times a day and then but the electricity bill is getting quite big, so I started to think about suspending the computer.

Of course the whole suspend feature has been used in laptops for ages but I guess not that much in Linux workstations. Occasionally I need to access my workstation remotely but that’s why there’s wake-on-lan and I still have my firewall computer always running.

I installed a package called hibernate and configured it a bit to suspend to RAM instead of suspending to disk. It takes only a few seconds to come up from the suspended state and I have all my windows right where I left them. Only the network connections get cut off, which is a bit annoying as I use SSH for certain things. There have been one or two occasions during the over a hundred suspends I’ve done so far, where the workstation hasn’t come up without extra kicking.

I measured the power consumption of two workstations with two different energy meters. One is a proper one from the electric company and one is a cheap one from a local store.

I conducted one to three measurements for each state and in the table below are the typical values.

Computer	State	W (Good meter)	W (Cheap meter)
1	Idle	55	65
1	Suspend	2	23
1	Off	1	23
2	Idle	98	87
2	Suspend	2	21
2	off	1	19

Based on these results, you do save some power by suspending the computer (and the cheap meter is close to useless). The actual amount of saved electricity depends on the total consumption in the idle state. Newer computers have decent power management and my workstation doubles the consumption from 100W to over 200W when I e.g. start an 3D game.