This feed contains pages in the "tech" category.
Apart from being somewhat slow, one of the downsides of the original Raspberry Pi SoC was that it had an old ARM11 core which implements the ARMv6 architecture. This was particularly unfortunate as most common distributions (Debian, Ubuntu, Fedora, etc) standardized on the ARMv7-A architecture as a minimum for their ARM hardfloat ports. Which is one of the reasons for Raspbian and the various other RPI specific distributions.
Happily, with the new Raspberry Pi 2 using Cortex-A7 Cores (which implement the ARMv7-A architecture) this issue is out of the way, which means that a a standard Debian hardfloat userland will run just fine. So the obvious first thing to do when an RPI 2 appeared on my desk was to put together a quick Debian Jessie image for it.
The result of which can be found at: https://images.collabora.co.uk/rpi2/
Login as root with password debian (Obviously do change the password and create a normal user after booting). The image is 3G, so should fit on any SD card marketed as 4G or bigger. Using bmap-tools for flashing is recommended, otherwise you'll be waiting for 2.5G of zeros to be written to the card, which tends to be rather boring. Note that the image is really basic and will just get you to a login prompt on either serial or hdmi, batteries are very much not included, but can be apt-getted :).
Technically, this image is simply a Debian Jessie debootstrap with a extra packages for hardware support. Unlike Raspbian the first partition (which contains the firmware & kernel files to boot the system) is mounted on /boot/firmware rather then on /boot. This is because the VideoCore expects the first partition to be a FAT filesystem, but mounting FAT on /boot really doesn't work right on Debian systems as it contains files managed by dpkg (e.g. the kernel package) which requires a POSIX compatible filesystem. Essentially the same reason why Debian is using /boot/efi for the ESP partition on Intel systems rather the mounting it on /boot directly.
For reference, the RPI2 specific packages in this image are from https://repositories.collabora.co.uk/debian/ in the jessie distribution and rpi2 component (this repository is enabled by default on the image). The relevant packages there are:
- linux: Current 3.18 based package from Debian experimental (3.18.5-1~exp1 at the time of this writing) with a stack of patches on top from the raspberrypi github repository and tweaked to build an rpi2 flavour as the patchset isn't multiplatform capable
- raspberrypi-firmware-nokernel: Firmware package and misc libraries packages taken from Raspbian, with a slight tweak to install in /boot/firmware rather then /boot.
- flash-kernel: Current flash-kernel package from debian experimental, with a small addition to detect the RPI 2 and "flash" the kernel to /boot/firmware/kernel7.img (which is what the GPU will try to boot on this board).
For the future, it would be nice to see the Raspberry Pi 2 support out of the box on Debian. For that to happen, the most important thing would be to have some mainline kernel support for this board (supporting multiplatform!) so it can be build as part of debians armmp kernel flavour. And ideally, having the firmware load a bootloader (such as u-boot) rather than a kernel directly to allow for a much more flexible boot sequence and support for using an initramfs (u-boot has some support for the original Raspberry Pi, so adding Raspberry Pi 2 support should hopefully not be too tricky)
One of the more exciting upcoming features of Farsight is the ability to change the amount of required bandwidth depending on network conditions. Which means Telepathy based VoIP clients will be able to use higher resolutions and better audio/video quality if the network connectivity allows. And ofcourse, when the available bandwidth is low, the bandwidth usage can be lowered such that calls are still possible with lower but hopefully still acceptable quality.
One side of the full story is measuring the available bandwidth, which hopefully Olivier will tell at some point. The other part is actually using less bandwidth. In case technical details are not that interesting to you, probably best to stop reading at this point..
An important way to control the bandwidth we're using in a call is setting the target bitrate on the encoding GStreamer element. While previously it was enough for us to set the bitrate before encoding started, we now need to be able to change it at runtime. And not only that, the codec implementation should ideally respond within a few frames and have a reasonable constant per-frame size.
All in all, a lot of requirements on codecs we didn't really have before. Which usually means we need to retest the various codecs we often use and make sure we configure them correctly for the behaviour we'd like to see (and fix them if necessary). To do this I've written a small test program, which simply changes the target bitrate over time and outputs some numbers suitable to feed into gnuplot to turn into graphs.
For example, when using x264enc with the current default farsight settings a part of the resulting graph looks something like this (full graph here):
The blue impulses is the per-frame size (scaled), the green line the bitrate average over 10 frames and the red line the target bitrate. Clearly this isn't an ideal picture, we will need to do some more tweaks to our default settings to make x264 behave the way we want. The same will be true for all other codecs and codec elements, at the moment the GStreamer VP8 element doesn't handle run-time bitrate changes at all and the Theora element acts it its very own interesting way (graph here)
A long time ago, 2006 according to git, I started helping out on the Pulseaudio packaging team. Didn't have much time back then, but that was fine as there was a quite active maintainer involved in the Team. Unfortunately for various reasons he no longer had time for his Debian work, since, oh around end of 2008. With myself not gaining more time (quite the contrary), that means the pulseaudio packaging hasn't had a lot of love for quite some time...
Updating the packaging for the lastest Pulseaudio release last weekend reminded me (again) that some fresh blood in pkg-pulseaudio would really be quite welcome. So for anyone that's looking for some nice new challenges, is interested in how pulseaudio and audio on linux in general works, and would like to help integrating pulseaudio in Debian even better please let us know and come join the team
Since some time the good people at NlNet have been sponsoring Collabora to add multi-party audio/video calling to XMPP and do an implementation of this in Telepathy. This project is otherwise known as Muji.
This work has resulted in:
- an experimental XMPP extension called Muji
- a new and more modern telepathy API for doing calls (currently still in draft), which allows multi-party calls as well as adding the possibility to support call forking (ringing multiple remote devices, call goes to the one that's picked up first).
- An implementation of both of these in telepathy-gabble
- A small telepathy client for testing and demo purposes.
To proof it actually works, a nice screenshot of the demo client in a 4-way call:
The screenshot is featuring myself in Collabora's UK office (top-left), Robert McQueen from a hotelroom in Taipei (top-right), Will Thompson and Magical trevor also from the Collabora UK office (bottom-left) and Mike Ruprecht from somewhere in Missouri. So we were quite spread out over our little planet. Both audio and video quality was quite good, even though the network in robs hotel was a bit flaky from time to time.
In case you want to try it out have a look at the MujiDemoClient page.
Yesterday Google announced the WebM Project, giving the world a new open and royalty-free video codec called VP8. Thanks to Collabora Multimedia and Entropy Wave support for it landed in gstreamer git shortly after the announcement.
In Telepathy we quite like video conferencing, so as a logical next step i quickly put together some proof of concept RTP payloading elements for Gstreamer with the obvious result:
The screenshot isn't very exciting, which is exactly how it should be. In the world i would like to live in people don't have to care about video codecs, whether it is for video calls, playing online media or whatever else they want to do with video. Looking at the list of supporters for the WebM project this may actually happen and that in my opinion is much is actually the most important aspect of it all.
The most important aspect that is missing at this point to bring VP8 as the video calling codec to the world is the lack of a standard RTP specification. Which is something we will hopefully start working on with various other parties in the WebM project reasonably soon. For now if you want to feel cutting edge get Empathy from git master and my rtp elements. To give things a first try
A Belorussian translation of this article is available here