Max

May 042014
 

Gestern erhielten wir ein Paket aus China, mit einem BananaPi als Inhalt. Wie grün noch ist diese in den Markt gebrachte Banane? Reift sie genauso wie “Banana Software” erst mit der Zeit nach?

Hier ist unser erster Eindruck von der neuen Platine, die dem Raspberry Pi Konkurrenz machen möchte!

Auspacken

BananaPi-Bubble-PackageBanana-Pi-CartonBox

BananaPi-ESD-bag

Unsere Banana Pi Platine kommt dick in Luftpolsterfolie eingewickelt, einem unbeschrifteten weißen Karton (schneller Markteintritt?), und natürlich in einem antistatischen ESD Beutel verpackt.

Sobald dieser Beutel aufgerissen ist, kann man den BananaPi in Ruhe von allen Seiten betrachten:

Banana-Pi-shot

Die Banane misst 92 mm x 60 mm, was ein wenig größer ist als unsere vertraute Beere (85 x 56 mm ).

Inkompatibel mit Raspberry Pi Gehäusen

Leider wird sie durch die größere Platinengröße, und auch die zusätzlichen Anschlüsse (z.B: SATA Anschluss), inkompatibel mit den meisten Raspberry Pi Gehäusen. Abgebildet ist das TEK-BERRY Gehäuse, das wir für fast alle unsere Raspberry Pi Produkte verwenden:

BananaPi-TEKBERRY-case

 

Anschlüsse / Interfaces

Der Banana Pi hat, wie der Raspberry Pi auch, zwei USB Ports, einen micro-USB Anschluss für Power (neben dem SATA Port, NICHT an der “gewohnten” R-Pi Position!).

Für Video-Ausgabe sorgen der HDMI Port, und ein RCA Jack (NTSC / PAL). Für Audio gibt es die gewohnte 3.5 mm Klinkenbuchse. Audio kann natürlich auch über den HDMI Port ausgegeben werden.

Er wird als Raspberry Pi kompatibel vermarktet, hat daher den gewohnten GPIO Pin Header mit UART, I2C, SPI, Power. Nach eigenen Angaben pin-kompatibel, noch nicht von uns getestet.

Er hat jedoch noch einige mehr Anschlüsse, bzw. vom Pi abweichend:

  • GBit LAN Anschluss
  • IR – Empfänger
  • USB OTG Anschluss (kann auch zum “powern” des B-Pis genutzt werden)
  • SATA Anschluss (& Power Header für SATA drives)

 

  • zusätzliche Pins (GPIO Port) –> CAN bus, ADC
  • Eingebautes Mikrofon (neben dem Audio Ausgang)
  • Drei Tasten (Reset, Power Key, Uboot Key)
  • Eine Custom programmierbare LED (beim Pi kann eine LED ebenfalls umfunktioniert werden)

Was wir bei dem Banana Pi vermissen ist eingebautes WiFi & Bluetooth, was bei dem Raspi auch wirklich, wirklich fehlt. Liebe Foundation, vielleicht bei Model C? In unseren Raspberry PI Kits legen wir daher oft einen WLAN Stick bei, der jedoch einen der USB Ports gleich belegt.

BananaPi-FrontBananaPi-Back

Die Fotos zeigen den Banana Pi von vorne und von hinten. Der SoC und die beiden RAM Chips sind hinten gut erkennbar. Bei dem Raspberry Pi befindet sich der Speicher direkt über dem SoC (d.h. das ist der Chip den wir eigentlich darauf sehen).

Folienkabel – Anschlüsse:

Der BananaPi hat einen DSI Display Connector, neben dem LAN Port, und einen CSI Camera Connector. Im Vergleich zum Pi sind diese damit genau umgekehrt! Durch veränderten Pitch sind die Stecker anders als beim Pi dimensioniert – 16 mm Breite des Folienkabels beim R-Pi (Kameramodul), ca. 20,5 mm Breite der Buchse beim R-Pi. Das BananaPi hat Buchsen für ein ca. 21 mm breites Folienkabel, und die Buchsen selber sind ca. 26 mm breit.

Das Kameramodul des R-Pis und dessen Software ist auf den Broadcom SoC des Pis optimiert, um beispielsweise direkt in H.264 aufzeichnen zu können.

Ich vermute, dass es mit einem Gewaltmarsch in Software, und evtl. Hardware-Rerouting möglich wäre, das Kameramodul des Pis an den Banana Pi anzubinden. “Out of the box” scheitert es jedoch allein schon an dem Steckverbinder.

Erweiterungen

Rund um den Raspberry Pi gibt es eine Vielzahl von Erweiterungen, beispielsweise auch unser Touch Display Modul, das per GPIO Kabel angebunden wird.

In diesem Fall (und falls der Header wirklich Pin-kompatibel ist, wie behauptet) hängt die Nutzung nur von der Software ab, die für den Banana Pi neu geschrieben werden muss. Unser Display ist beispielsweise noch nicht kompatibel mit dem Banana Pi, da es ein besonderes Kernel-Modul, das für den R-Pi Kernel kompiliert wurde, benötigt. Da dieser Kernel wiederum für den R-Pi ist, dürfte er auf dem Banana Pi nicht starten, oder es könnte Unterstützung für diverse Hardware fehlen.

BananaPi-Ribbon-Cable

Viele der Erweiterungen werden allerdings speziell für den Formfaktor des Raspberry Pis hergestellt. Beispielsweise sieht man in den folgenden zwei Bildern das beliebte PiFace. Links auf dem Banana Pi, rechts auf dem Raspberry Pi:

BananaPi-PiFaceRaspberry-Pi-Piface

Wie man auf dem linken Bild erkennen kann blockiert der anders angebrachte LAN Port des Banana Pis das erfolgreiche Einstecken des PiFaces! Dieses kann jetzt nur noch über spezielle Adapterplatinen, wie bspw. Farnell’s Multi-breakout Board angeschlossen werden.

Das ist wichtig zu wissen, bevor man den Banana Pi kauft.

Auch Erweiterungen die einen wesentlich kleineren Footprint haben können problematisch sein:

BananaPi-RasClock

Die RasClock, Realtime Clock für den Raspberry Pi, lässt sich gut stecken. Mit dem Batteriehalter, und damit +3V berührt sie jedoch einen der Pins des BananaPis! Das ist auf dem Foto bei genauem Hinschauen zu erkennen.

Die Entfernung zwischen Composite Port und GPIO Header ist ebenfalls eine andere, dadurch sind weitere Erweiterungsplatinen inkompatibel. Raspi.TV hat ein Foto.

Hardware & Software

Der Banana Pi hat im Vergleich zum Raspberry Pi einen deutlich leistungsfähigeren, Dual-Core AllWinner A20 SoC – ARM Cortex A7 basierend.

1 GB DDR3 SDRAM im Vergleich zum R-Pi sind ein schöner Sprung, es gibt jedoch bereits Embedded-Boards mit noch mehr RAM.

Die Mali 400 GPU des BananaPis (ARM Mali400MP2) ist OpenGL ES 2.0/1.1 fähig.

In den SD/MMC Slot können bis zu 64 GB Karten eingesteckt werden, und bis zu (angeblich) 2 TB Festplatten an den SATA Anschluss angeschlossen werden. Ich vermute, dass auch größere Festplatten möglich sein sollten.

Die zwei USB Ports sind direkt an den AllWinner SoC angebunden, dadurch ist natürlich der Gesamtdurchsatz je Port im Vergleich zum Pi erhöht. (Der Pi bindet LAN, und beide USB Ports über einen einzigen tatsächlichen USB Port des SoCs an.)

Strom erhält der Banana Pi über einen oder beide Mikro-USB Ports. Er benötigt 1,7 A im Vergleich zu dem deutlich genügsameren R-Pi mit 750 mA. Wir haben mit einem 2 A Netzteil getestet.

Gebootet wird der Banana Pi genauso wie der Raspberry Pi von der SD Karte.

Nicht kompatibel mit SD Karten für den Raspberry Pi

Mein erster Versuch war, direkt von einer für den Raspi bespielten SD Karte zu booten. Fehlanzeige – der Bildschirm blieb dunkel, nur eine LED leuchtete.

Es müssen speziell für das System erstellte Images heruntergeladen werden. Es gibt ein auf Raspbian basierendes Image, das sogar die Raspbian Repositories für Software-Installation nutzt.

Es ist jedoch eigentlich sinnvoller, falls man nicht auf die Raspbian – Ökosphäre angewiesen ist, ARMv7 – Repositories / Software zu nutzen. Beispielsweise wird dank ARMv7 Ubuntu unterstützt, oder nach eigenen Angaben auch Android 4.4.

Für Android gibt es momentan allerdings nur ein Android 4.2 Image zum Download.

BananaPi-and-Picard

Mit unserer half-size SD Karte pi.card ist der Banana Pi kompatibel. Die Karte lässt sich nicht ganz so leicht wie bei dem Raspberry Pi entfernen, schließt jedoch bei dem Banana Pi bündig mit dem Rand ab.

pi.card wird also mit allen für den Banana Pi erscheinenden Gehäusen kompatibel sein. Mit den passenden Images für den Banana Pi kann man pi.card mit unserem beiliegenden SMILE SD Reader an jedem Rechner bespielen.

Raspbian auf dem Banana Pi Board

Das Image kann man von http://www.lemaker.org herunterladen (Google Drive Mirror). Raspi.TV hat in ihrem Review darauf hingewiesen, dass das Image für manche 8 GB Karten zu groß ist, daher habe ich es nach dem Entpacken gleich auf eine 16 GB Karte gespielt.

Das System startet direkt nach dem Boot in den Desktop (kurze Wartezeit mit dunklem Bildschirm inklusive).

Wie bereits beschrieben ist die Raspbian Repository eingebunden, und Pakete können wie gewohnt mit aptitude install installiert werden, z.B. aptitude install chromium

Chromium funktioniert, ebenso wie Midori.

Alles, inklusive den Browsern, und der Paketinstallation läuft spürbar schneller als auf dem Pi, jedoch für meine (vielleicht sehr anspruchsvollen?) Surf-Bedürfnisse immer noch ZU langsam (Seitenaufbau, Reaktionszeiten).

Das gleiche gilt auch für raspi-config, mit dem man z.B: die Tastatur konfigurieren kann. Ich bezweifle dass Übertakten, etc. aus raspi-config heraus funktionieren wird, ausprobiert habe ich es jedoch noch nicht.

Bei unserem Test hatte der HDMI Ausgang nach einem Time-Out ausgeschaltet. Auch durch Tastaturdruck / Mausbewegung konnte der Bildschirm nicht reaktiviert werden. Vielleicht eine Einstellungssache?

omxplayer

omxplayer ist zwar installiert, beendet sich aber mit der Fehlermeldung

“* failed to open vchiq instance”

egal ob man ihn als root oder user pi ausführt.

Das war nicht anders zu erwarten, ist doch omxplayer für OpenMAX, und insbesondere den VideoCore IV, die GPU des Raspberry Pi SoCs entwickelt worden. Die Mali GPU des Banana Pis muss anders angesprochen werden!

vlc

vlc konnten wir leider nicht testen, da es sich nicht installieren ließ. Das könnte mit den benötigten Reboots zusammenhängen (siehe oben: HDMI Time-Out)

Noch keine Unterstützung für WiringPi, RPi.GPIO

Gemäß Raspi.TV hat der Banana Pi (dort liebevoll ‘nana genannt) noch keine High-Level Unterstützung der GPIO Ports für Python, etc. Das wird sich bestimmt mit der Zeit ändern (Kernel-Unterstützung), hängt jedoch auch sehr von der Community-Größe ab. Hier hat der Pi die Nase eindeutig vorne.

Für GPIO-Interfacing sind darüber hinaus die Prozessor / Netzwerk Fähigkeiten des Pis vollkommen ausreichend – wenn man die Daten aufwendig weiterverarbeiten möchte währe eventuell ein zusätzlicher Server, beispielsweise eine virtuelle Maschine, aktuell eine interessantere Wahl als die Banane.

Android auf der Banana

Das Android Image von lemaker.org kann NICHT mit Win32DiskImager geschrieben werden. Es muss ein Tool von Allwinner dazu genutzt werden (PhoenixCard). Wir haben es aufgrund von Sicherheitsbedenken nicht getestet, da dieses Tool leider nicht direkt auf der Allwinner Seite herunterzuladen war.

Hier ist die benötigte Anleitung.

Fazit

Der Banana Pi ist eine gute Idee, jedoch steckt der Teufel in den Details:

  • Viele Raspberry Pi Erweiterungen mechanisch inkompatibel
  • Gehäuse inkompatibel
  • Software muss neu erstellt und angepasst werden (z.B. Kernel-Treiber)
  • Leistungssprung relativ gesehen nicht “sensationell”, potentiell schlechtere Grafik-Performance / Hardware Encoding / Decoding (noch zu wenig Infos darüber verfügbar)

Für Bastler, die nur den GPIO Port mit Python, etc., nutzen wollen, ist der Raspberry Pi nach wie vor erste Wahl. Hierbei spielt der langsame Prozessor keine solche große Rolle. Je nach eigenen Fähigkeiten sind auch Arduino-kompatible Boards sehr, sehr interessant. Ich sehe hier für den BananaPi nicht den Schlüsselmarkt.

Für NAS / … Anwendungen kann man entweder auf dedizierte Hardware zurückgreifen (die preislich mit Gehäuse etwa gleich liegt), oder auf einen leistungsfähigen Intel Atom SoC / bald auch auf einen AMD ARM64 setzen. Intel’s Minnowboard Max bietet z.B:

  • 64 bit Intel Atom SoC, auch als dual-Core erhältlich
  • 2 GB DDR RAM
  • einen USB 3.0 port (!)
  • PCI Express Gen 2.0 Lane

Es ist zwar natürlich teurer als der Raspberry Pi, und als der Banana Pi – aber auch deutlich leistungsfähiger und zukunftssicherer dank USB 3.0!

Für CloudComputing – Anwendungen ist der Formfaktor des Rpis / des BPis uninteressant, da nicht platzoptimiert, auch die Leistung per € / $ ist zu niedrig.

Summa summarum wirkt der Banana Pi auf uns momentan noch sehr unreif – wir empfehlen zu warten, bis die Plattform reifer wird, oder zu einer Alternative zu greifen.

Gute Alternative: HummingBoard

Wer von dem Banana Pi nicht ganz überzeugt ist:

Eine weitere Raspberry Pi “look-alike” Plattform, HummingBoard von SolidRun steht schon in den Startlöchern. Falls die Abmessungen der Platine, und deren Konnektoren kompatibler zum R-Pi sind, wäre schon viel gewonnen.

SolidRun geht beim Aufbau der Plattform und Community auf jeden Fall geschickter vor – die Platine befindet sich jetzt erstmal in den Händen von Entwicklern, auch für OpenELEC / Raspbmc Unterstützung wurde von Anfang an gesorgt. Wer auf den Raspi-Formfaktor verzichten kann, kann bereits jetzt bei SolidRun einen Computer in Form eines kompakten, passiv gekühlten Würfels bestellen.

Leider hat auch das HummingBoard keinen WiFi on-board support. Bei den anderen SolidRun Modellen ist WiFi teilweise eingebaut.

Momentan ist das HummingBoard noch nicht verfügbar. Bei entsprechender Nachfrage (bitte um Kontakt) werden wir uns überlegen, es auch in unser Sortiment als “Highend Raspi” aufzunehmen.

Referenz & further reading:

Apr 272014
 

Starting from today, we are offering free (uninsured) shipping to the United Kingdom for all products in our new international shop:

www.pi3g.com/shop

British-Edition-Raspberry-Pi-free

Get your unique British Edition kit now Smile! It sports our 16 GB pi.card half-size SD card as additional unique feature!

raspberry-pi-with-pi.cardraspberry-pi-topview-pi.card

We will be adding a choice of additional kits with British power supply units, soon.

Apr 212014
 

This is heavily based on this Wiki entry. Go there to read more about the background of toolchains.

As a quick summary for you: we want compilation to be faster than on the Raspberry Pi. MUCH faster.

Set up crosscompiling

Create / use an Ubuntu machine. I use 12.04 LTS.

You can check your Ubuntu version with lsb_release –a

Run the commands:

sudo add-apt-repository ppa:linaro-maintainers/toolchain

This will add the linaro toolchain repository.

sudo add-apt-repository "deb http://archive.ubuntu.com/ubuntu $(lsb_release -sc) main universe restricted multiverse"

This will add the universe repository and all other available repositories (universe being the one we need additionally).

aptitude update

To get the contents from the repositories. Now install the crosscompiling toolchain:

apt-get install gcc-arm-linux-gnueabi

dpkg -L gcc-arm-linux-gnueabi

This will show the location of the newly installed libraries.

Official note:

Note that this toolchain defaults to ARMv7 with Thumb2. If you want to use it for older processors you have to add “-marm” into CFLAGS.

Apr 212014
 

First of all, remove xpra and cython if you had them installed:

aptitude purge xpra cython

Update your package lists, as we are going to install a lot of packages:

aptitude update

Prepare required prerequisites

Then follow the instructions on the xpra Wiki for building Ubuntu / Debian style:

apt-get install libx11-dev libxtst-dev libxcomposite-dev libxdamage-dev \ python-all-dev python-gobject-dev python-gtk2-dev

apt-get install xvfb xauth x11-xkb-utils
apt-get install libx264-dev libvpx-dev libswscale-dev libavcodec-dev

The file mentioned in the how-to, vpx.pc should exist:

cat /usr/lib/pkgconfig/vpx.pc

You will need to install and compile Cython from sources, as the version in the Raspbian repository is too old (0.15.1 vs. 0.16 minimum needed).

wget http://www.cython.org/release/Cython-0.20.1.tar.gz
tar -xzf Cython-0.20.1.tar.gz

change into the newly extracted directory. Install cython:

python setup.py install

This will take quite a while. Test that you have the correct cython version:

cython --version

should yield Cython version 0.20.1

Download and extract source

wget https://www.xpra.org/src/xpra-0.12.3.tar.bz2
tar -xjf xpra-0.12.3.tar.bz2

Note: there may be a newer package, check, please.

Change into the extracted directory. We need to apply a patch:

patch < patches/old-libav.patch

Enter xpra/codecs/dec_avcodec/decoder.pyx as the file to patch

Next patch (several files in one go):

patch < patches/old-libav-pixfmtconsts.patch

Simply copy and paste the “Index file” the patcher asks for, for example xpra/codecs/csc_swscale/colorspace_converter.pyx

Next patch (also several files):

patch < patches/old-libav-no0RGB.patch

Act like above (copy & paste file name, without leading / ).

It also contains a useful README, which tells you the next step is:

./setup.py install --home=install

After the compilation is done, you should either (always) set the Pythonpath to include the install subdirectory, like this:

export PYTHONPATH=$PWD/install/lib/python:$PYTHONPATH

or install the “finished” files to the appropriate targets. From the install directory do:

cp bin/* /usr/bin/.
cp -R lib/* /usr/lib/.
cp -R share/* /usr/share/.

xpra will now be the newest version:

xpra –version

xpra v0.12.3

You will still have to set the PYTHONPATH to the new files in /usr/lib/python, though:

The PYTHONPATH environment variable needs to be set:

export PYTHONPATH=/var/lib/python:$PYTHONPATH

 

Test & Test results

OK, here’s how to set up a test session:

Set up a test server, which has xpra installed (you can install it through the winswitch packages, will get you the newest xpra version on Ubuntu & Debian)

Start X Windows, open LXTerminal, run the following commands.

export PYTHONPATH=/var/lib/python:$PYTHONPATH

Start an xpra session via SSH (can be killed using Ctrl-C, and reconnected to using the same command):

xpra start ssh:maxcs@192.168.1.61:122 –start-child=xterm –encoding=h264

Read the manpage (man xpra) to have a look at some other options

Test results

xpra-raspberry-h264

rgb, png encodings are too high-latency.

jpeg is barely usable, even when resizing the application (for instance Abiword) to not full-screen usage.

webm encoding delivers worse quality, but seems a bit more usable

h264 decoding is NOT done in hardware in the default code (we’ll look into this). Surprisingly it is still the “most fluid to use” one.

I suspect that no decoding in H.264 is taking place, and server side xpra falls back to a different encoder (webm?) Anyways, one can even “watch” videos (a couple of frames each second with heavy artifacts) with this.

For very light administration / checking of remote contents, etc. xpra can be used as is. We will need to enable hardware decoding of h264, though, for it to yield real benefits.

Please note: our interests solely rest in streaming TO the Raspberry Pi, not FROM the Raspberry Pi – we will not test / patch in order to speed up administration of the Pi at this point.

 

Notes & Further reading

Dependencies of xpra package:

(you can show this using “apt-cache showpkg xpra” on a machine which has the package in the newer version, e.g. Ubuntu AMD64):

Dependencies:
0.12.3-1 – python2.7 (0 (null)) python (2 2.7.1-0ubuntu2) python (3 2.8) libavcodec53 (18 4:0.8-1~) libavcodec-extra-53 (2 4:0.8-1~) libavutil51 (18 4:0.8-1~) libavutil-extra-51 (2 4:0.8-1~) libc6 (2 2.14) libgtk2.0-0 (2 2.24.0) libswscale2 (18 4:0.8-1~) libswscale-extra-2 (2 4:0.8-1~) libvpx1 (2 1.0.0) libx11-6 (0 (null)) libx264-120 (0 (null)) libxcomposite1 (2 1:0.3-1) libxdamage1 (2 1:1.1) libxext6 (0 (null)) libxfixes3 (0 (null)) libxrandr2 (2 4.3) libxtst6 (0 (null)) python-gtk2 (0 (null)) x11-xserver-utils (0 (null)) xvfb (0 (null)) python-gtkglext1 (0 (null)) python-opengl (0 (null)) python-numpy (0 (null)) python-imaging (0 (null)) python-appindicator (0 (null)) openssh-server (0 (null)) python-pyopencl (0 (null)) pulseaudio (0 (null)) pulseaudio-utils (0 (null)) python-dbus (0 (null)) gstreamer0.10-plugins-base (0 (null)) gstreamer0.10-plugins-good (0 (null)) gstreamer0.10-plugins-ugly (0 (null)) python-gst0.10 (0 (null)) openssh-client (0 (null)) ssh-askpass (0 (null)) python-numeric (0 (null)) python-lz4 (0 (null)) keyboard-configuration (0 (null)) xpra:i386 (0 (null))

CheckInstall

Optional: install checkinstall, to create a package which you can easily remove or re-deploy to other computers:

aptitude install checkinstall

 

Troubleshooting

Patches

error: implicit declaration of function ‘avcodec_free_frame’

you need to apply the patch patches/old-libav.patch

error: ‘AV_PIX_FMT_YUV420P’ undeclared

you need to apply the patch patches/old-libav-pixfmtconsts.patch

error: ‘PIX_FMT_0RGB’ undeclared

you need to apply the patch patches/old-libav-no0RGB.patch

The other patches were NOT needed in my experimental compilation.

 

ImportError: No module named xpra.platform

Once you try to execute xpra (from LXTerminal preferably), you may get this message. The PYTHONPATH environment variable needs to be set:

export PYTHONPATH=/var/lib/python:$PYTHONPATH

Apr 202014
 

We’re working on streaming a multimedia remote desktop to the Raspberry Pi.

In the future we envision, you shall be able to use a webbrowser on the Pi at normal speeds – including YouTube videos, etc. – operate with CPU / GPU intensive applications – as all the processing is done on a server, and just the H.264 stream rendering on the Raspberry Pi.

First steps

A very interesting application stack to serve this purpose is already available: WinSwitch & xpra

Look at the WinSwitch homepage for installation instructions – it is really quite easy.

WinSwitch bundles several remote clients (VNC / xpra / RDP) with an easy-to-use interface, and broadcasts servers / clients (via Avahi / Bonjour).

A very first demonstration of the capabilities of this stack can be obtained installing WinSwitch on your “normal” desktop machine, and on a server.

Server

As a server we currently use the “fastest available” Intel Atom processor currently on the market –  Intel(R) Atom(TM) CPU  C2750. We are looking into using AMD’s ARM 64 bit processor as server hardware in the future (power-efficiency!), and the performance should be roughly comparable.

Client

As a client we use a Dell Inspiron notebook (with Windows 8.1), Core i7 processor, FullHD resolution.

There is a xpra package available for the Raspberry Pi, which is based on a quite old version of xpra, and will not connect to our server. This may be related to the huge version difference between the two packages, wrong setup, or special tweaking done by winswitch to xpra.

Test results

YouTube videos

We can stream a webbrowser running YouTube fullscreen in FullHD, which will use about 50 % of the server’s total resources (decoding one or several videos in FullHD, encoding one FullHD stream). This is possible in low-latency, at about 30fps and high quality. Yes, this does include an audio stream, too.

The stream uses about 40 Mbp/s of bandwidth, and is much more reliable (less choppy) if streamed over LAN, instead of WLAN. In fast-moving scenes video will still be a bit choppy, but tolerably.

The encoding is done in software, using x264.

Streaming ONE browser window is possible with our server hardware in good quality (for video content) from either the host directly, or from a virtual Ubuntu machine (KVM-virtualized) inside it.

TWO browser windows will start to degrade the quality, even if trying to force best quality and lowest latency.

image

This screenshot shows the YouTube video in the browser being streamed on the client.

Application streaming

Winswitch allows you to stream single applications. Performance / latency is very good on a local network, keyboard / mouse delay is barely noticeable.

In general, applications will be quite useable and seem responsive.

Applications requiring precise mouse / screen cordination, like graphics software will not be usable (at least with our hardware setup).

image

This screenshot shows Firefox being streamed through xpra.

image

VLC media player being streamed – sound works

image

GIMP: barely usable (too much delays)

image

word processing with AbiWord: OK performance (could be better, but it’s usable)

 

Desktop streaming

Streaming a desktop with xnest / Xephyr / xpra from inside a virtualised Ubuntu container on the base hardware is NOT possible at low-latency (30 fps) with high-quality. (With our server hardware)

In order to test it, you have to install additional packages on the server:

aptitude install xnest xserver-xephyr

and set the desktop default to xpra, possibly after restarting the server / client:

image

Apparently frame-grabbing / mirroring the desktop / going through the X layer uses up much more processor resources.

image

Gameplay is quite smooth – but full screen video playback would be a problem.

Some hints

  • authentication with private/public key pairs may be problematic without additional configuration, for first tests I recommend to re-enable password login for SSH.
  • audio for the browser may require alsa and pulseaudio
  • This does not work on the Raspberry Pi yet, this is our next step (compiling a package for it).

 

Outlook

  • encoding performance and latency may be enhanced significantly using NVidia’s NVENC hardware encoding / framegrab API – which xpra supports.
Apr 192014
 

libavg is a German project to ease the building of multimedia applications – this can be anything from a movie / touch interface installation in a museum to a quick demo of a future application you throw together yourself, before (if needed) delving into “hardcore” programming.

libavg supports a variety of text, graphics, audio and video output, and a variety of input possibilities (e.g. multitouch). Have a look at their showcase to see some of the possibilites.

Luckily for us, libavg has been ported and optimized for the Pi, and they provide a pre-compiled package.

Installation

Follow the instructions on https://www.libavg.de/site/projects/libavg/wiki/RPI for installing the tarball (see link at the bottom of the page, which you can “wget”.

There are also instructions for compiling from source, using QEMU, on that page.

Usage

After installation, you can test libavg with the classic “hello world” program.

Please refer to this page https://www.libavg.de/site/projects/libavg/wiki/HelloWorld for the source.

One gotcha: X Windows needs to be running in order for the program to execute. (“startx”). Else the software will complain:

RuntimeError: No available video device

Video

Video playback is NOT hardware accelerated on the Pi currently with libavg.  In my test a H.264 encoded low-res movie was played at normal speed, but seemed quite choppy. Audio was OK. Decoding and rendering happens via the CPU (as per the “node” idea – combining multiple videos / other nodes for output), which maxes it out. The same video works fine using omxplayer, though.

In this blog article the team announces intentions to work on OpenMax IL integration. In the same article, a comment states that as per January of 2014 there has been no work done in this area, lacking necessary manpower & knowledge resources for the development.

Documentation

libavg has an extensive documentation, for instance this page for area nodes (including the video node).

It also has a blog, with some interesting entries, for example:

Video decoding using libav and ffmpeg – detailing some of the problems behind video decoding in general, and libav/ffmpeg in particular.

Apr 042014
 

This is a quick introduction how to calibrate our touchscreen.

display-bausatz-einzelteile

I freely admit this is heavily based on Adafruit’s tutorial – I hope we will be able to return the favour for you guys one day!

I suggest for you to run the commands in the following tutorial in a separate SSH shell, opened from an additional computer (why not simply buy a second Raspberry Pi from you-know-whom?) .

Also, the commands in this tutorial are supposed to be run as root! –> “sudo su” gets you into the root user from the pi user.

Some background information:

Our touchscreen is based on the ADS7843 (compatible with ads7846 driver) chip, which you can see being activated (on our image) by calling lsmod:

sudo lsmod

Module                  Size  Used by
fuse                   76348  3
evdev                   9407  4
joydev                  9084  0
ads7846                 7849  0
ads7846_device          6049  0
spi_bcm2708             4728  0
snd_bcm2835            16165  0
snd_soc_bcm2708_i2s     5474  0
regmap_mmio             2806  1 snd_soc_bcm2708_i2s
snd_soc_core          131356  1 snd_soc_bcm2708_i2s
regmap_spi              1897  1 snd_soc_core
snd_pcm                81585  2 snd_bcm2835,snd_soc_core
snd_page_alloc          5156  1 snd_pcm
regmap_i2c              1645  1 snd_soc_core
snd_compress            8108  1 snd_soc_core
snd_seq                53769  0
snd_timer              20133  2 snd_pcm,snd_seq
snd_seq_device          6473  1 snd_seq
leds_gpio               2059  0
led_class               3688  1 leds_gpio
snd                    61299  7 snd_bcm2835,snd_soc_core,snd_timer,snd_pcm,snd_seq,snd_seq_device,snd_compress

/dev/input/event0

This driver “delivers” the finished information to the device /dev/input/event0 – you can verify this by doing

sudo cat /dev/input/event0

and touching the touchscreen (preferably with our stylus!) – it will spew out a garble of binary information on each touch. Use Ctrl + C to terminate the command.

Note: If this command does not react to input from the touchscreen, try moving your mouse / typing on the keyboard you’ve attached to the Raspberry Pi –> it may be assigned differently on your system. Adjust the following commands accordingly … !

/dev/fb1

Our touchscreen is set up as framebuffer device 1 – you can test this like this:

cat /dev/zero > /dev/fb1

Will turn your little screen black (and give you an error message to go with it, free of charge, naturally).

libts

Tslib is a library which serves as common abstraction layer for events on touchscreens. It includes filters (for instance for smoothing the events and calibrating).

Calibration

Install the touchscreen utilities (Tslib):

aptitude install libts-bin

This will create a configuration file, /etc/ts.conf, which you might want to modify some day (have a look at the manpage first, maybe).

In order to use ts_calibrate and ts_test, you need to set environment variables.

export TSLIB_TSDEVICE=/dev/input/event0
export TSLIB_FBDEVICE=/dev/fb1

This will set them temporarily for the current user and current console you’re working on.

Then, start the calibration process:

ts_calibrate

This will show a screen with a crosshair. And instructions.

Touch the crosshair’s center with your stylus. Repeat the procedure, until the software exits.

The calibration data will be shown on your console. It will look something like this:

xres = 320, yres = 240
Took 16 samples…
Top left : X = 3110 Y =  934
Took 6 samples…
Top right : X =  696 Y =  979
Took 14 samples…
Bot right : X =  711 Y = 3163
Took 10 samples…
Bot left : X = 3161 Y = 3115
Took 8 samples…
Center : X = 1915 Y = 2070
330.695190 -0.090429 0.001365
-13.946960 0.001227 0.064123
Calibration constants: 21672440 -5926 89 -914028 80 4202 65536

 

This data will be written to the calibration file /etc/pointercal :

root@raspberrypi:/home/pi# cat /etc/pointercal
-5926 89 21672440 80 4202 -914028 65536536

Test

You can test the calibration using

ts_test

This will display a crosshair for you to move and drag around. You can also switch to drawing mode, and draw something.

Do not forget to set up the environment variables, if you run the command from another console.

 

X-Calibration and further knowledge

Please refer to Adafruit’s tutorial. The section on calibrating X is also applicable to our display.

The symlinking of the input device (/dev/input/event0 to /dev/input/touchscreen) mentioned in the tutorial will not work with our touchscreen and it’s current driver, the command has to be modified for that.

Troubleshooting

evtest

Evtest can help you to troubleshoot device input.

Install it using

aptitude install evtest

run it on the device you want to test, e.g. what the touchscreen should default to:

evtest /dev/input/event0

This will show you more information than the crude “cat” test suggested at the beginning of this article. It will also allow you to see keyboard events from your keyboard if you have one attached to the Pi (use /dev/input/event1 if you attached it as first USB device, before a different input device).

 

ts_test:

/dev/touchscreen/ucb1x00: No such file or directory

This error message will show, if you did not set the environment variables. Keep in mind, that you either have to set them manually from each (!) console / user (!) you open or operate as, or permanently in the appropriate location.

Check which environment variables are set by using:

set

you should see

TSLIB_FBDEVICE=/dev/fb1
TSLIB_TSDEVICE=/dev/input/event0

amongst the other output.

 

ts_calibrate:

ts_open: No such file or directory

This error message will show, if you did not set the environment variables. Keep in mind, that you either have to set them manually from each (!) console / user (!) you open or operate as, or permanently in the appropriate location.

Check which environment variables are set by using:

set

you should see

TSLIB_FBDEVICE=/dev/fb1
TSLIB_TSDEVICE=/dev/input/event0

amongst the other output.

 Posted by at 10:37 pm
Optimization WordPress Plugins & Solutions by W3 EDGE