How To: Externe Mikrofone mit dem Android Smartphone nutzen

Tolle Videoqualität, aber der Ton ist stellenweise mau, wer hat sich nicht bereits nach einem externen Mikrofon für das neue Android Smartphone gesehnt? Ob es möglich ist externe Mikrofone am eigenen Smartphone zu verwenden und welche Voraussetzungen dafür geschaffen werden müssen, das soll dieser Artikel so gut wie möglich darstellen.

3,5mm Klinkenanschluss 4-Pol und 3-Pol vor Smartphone mit Headsetanschluss
3,5mm Klinkenanschluss 4-Pol und 3-Pol vor Smartphone mit Headsetanschluss

Je aktueller das Smartphone, so leistungsfähiger die Kamera – diese Aussage trifft beinahe immer zu und die Videos (Full HD ist im oberen Segment mittlerweile Standard) sind von überraschend guter Qualität, gerade wenn das Umgebungslicht ausreichend vorhanden ist. Wozu noch eine dedizierte Videokamera kaufen, wenn die Smartphones durchaus überzeugende Qualität liefern und man nicht auf entsprechende Gläser (Objektive) angewiesen ist oder sich frei im Brennweitenbereich bewegen, also „optisch Zoomen“ will. Die Bildqualität ist tatsächlich ansehnlich, das hier verlinkte Video ist mit dem Samsung Galaxy Note und einem Dauerlicht (Einstell-Licht eines Studioblitzes) aufgenommen worden. Selbst bei Zuhilfenahme künstlichen Lichtes, ist die HD-Qualität, gerade für unsere Zwecke von Produktaufnahmen, vollkommen akzeptabel. Nun hat das verwendete Samsung Galaxy Note eine sehr ordentliche Qualität, was die Sprachaufzeichnung mittels des eingebauten Mikrofons anbetrifft – andere Smartphones schneiden hier spürbar schlechter ab, liefern ein permanentes Hintergrundrauschen oder ähnliche Probleme. So gut die eingebauten Mikrofone auch sein mögen, immer dann wenn zunehmend Umgebungs- und Störgeräusche hinzukommen wird es sehr schnell sehr eng mit der Sprachaufnahme.

Externe Mikrofone helfen in den vorgenannten Fällen, gerade gerichtete Mikrofone sind ideal geeignet um Umgebungsgeräusche durch die Charakteristik des Mikrofons quasi auszublenden. Leider funktioniert so gut wie kein Mikrofon direkt am Smartphone, was am entsprechenden 4-poligen Headsetanschluss liegt, der von der grossen Masse der Smartphones genutzt wird.

3,5mm Klinke Headset 4-Pol und 3,5mm Klinke 3-Pol Mikrofon
3,5mm Klinke Headset 4-Pol und 3,5mm Klinke 3-Pol Mikrofon

Schnell kommt man in die Verlegenheit, nachdem man sich den 3,5mm Klinkenanschluss des Headsets ansieht, ein vorhandenes PC-Headset oder ein Mikrofon, welches man ebenfalls bereits am PC im Einsatz hatte, mit dem Smartphone zu verbinden, schliesslich handelt es sich beim Anschluss doch um einen identischen 3,5mm Klinkenstecker. Was beim Kopfhörern klappen mag, scheitert in nahezu allen Fällen am Mikrofon, weil die Belegung des Klinkensteckers¹ nicht passt, Die im Smartphone verwendeten Klinkenanschlüsse erwarten einen 4-poligen Stecker, meist in der Belegung L,R,GND,Mic in der Anordnung TRRS, also von der Spitze (Tip) zu den beiden Kontakten zwischen den Ringen 1 und 2, hin zum Sleeve, also den Bereich am oberen Ende. Ältere Stecker haben häufig GND und Mic vertauscht, entsprechende Mikrofone die die zuerst beschriebene Anordnung besitzen, funktionieren an diesen Geräten nicht – es helfen nur Adapter, die die Belegung kreuzen (z.B. Amazon: Headset-Adapter für 4-polige (TRRS) 3,5-mm-Klinkenstecker / ändert die Pinbelegung).

Ebenfalls äusserst hilfreich ist die Seite pinoutsguide.com, hier findet man die konkrete Belegung der Headsets vieler Smartphones: Link zur Übersichtsseite auf pinoutsguide.com

Man hat also zwei Möglichkeiten externe Mikrofone mit dem Smartphone zu verwenden:

  • Nutzung eines vorhandenen Mikrofons in Kombination mit einem entsprechenden Adapter(kabel)
  • Nutzung eines dedizierten Mikrofons für den vorhandenen 4-poligen 3,5mm Klinkenanschluss (Siehe Test zum micW i266)

Zuerst muss sichergestellt werden dass das verwendete Smartphone zur Aufzeichnung von Videos mit „eingespeistem“ Audiosignal eines externen Mikrofons überhaupt geeignet ist. Je nach Hersteller, Androidversion und vorhandener Kamerasoftware ist dies leider unterschiedlich und eine allgemeine Aussage kann nicht getroffen werden. Der Test ist im Video beschrieben, hier in Kurzform:

  1. Kameraanwendung öffnen
  2. Videoaufnahme auswählen
  3. Aufnahme starten
  4. Sprache aufzeichnen um ein Beispiel mit internem Mikrofon zu haben
  5. Das mitgelieferte Headset anschliessen
  6. Weiter Sprache aufzeichnen
  7. Aufnahme beenden
  8. Aufnahme abspielen

Sollte man nun keinen Unterschied zwischen dem Teil der Aufnahme feststellen, die ohne angeschlossenes Headset durchgeführt wurde, und dem Teil, zu dem das Headset angeschlossen wurde, sind die Voraussetzungen um Aufnahmen mit einem externen Mikrofon und dem Smartphone zu erstellen denkbar schlecht. Es kann an der Kamerasoftware liegen, die fest auf die Aufnahme mit dem verbauten internen Mikrofon eingestellt ist oder oder oder. Mit den beiden vorhandenen Geräten Samsung Galaxy Note und dem Sony Ericsson Xperia PLAY klappten externe Mikrofone reibungslos. Sollte man Probleme haben, kann man es mit der App lgCamera (Android Market Direktlink) probieren, diese bietet die Möglichkeit den Mikrofoneingang zu steuern.

Wer sich all das lieber in Videoform anschaut und beschreiben lässt, der legt nun los und tobt sich auf YouTube aus:


YouTube Direktlink

Es gilt immer zu bedenken: Egal was angeschlossen werden soll, es muss in einen 3,5mm Klinkenanschluss mit 4-poliger Belegung enden!

Mit diesem Gedanken im Kopf kann man theoretisch alles anschliessen, wofür sich ein Adapter auftreiben lässt. Vorhandene PC-Headsets kann man mittels Y-Splitter anschliessen (z.B. Amazon: Adapter PC-Headset 2-mal 3,5-mm-Stecker an 4-poliger Kupplung) oder grösse Studiomikrofone mit XLR Anschluss, für die es ebenfalls Adapter gibt. Zweitere sind in Deutschland leider schwerer zu bekommen, im Audiofachhandel kann man sich entsprechende Adapter zumindest zusammenlöten lassen, online war ich bisher nur in den USA halbwegs erfolgreich- kV Connection hat Kabel und Adapter für alles und jeden, auch für unseren 3,5mm Klinkenanschluss und ein Mikrofon mit XLR-Port.

An Adaptern funktionieren passive Mikrofone, alles was Strom braucht muss seperat versorgt werden, also mittels Batterien oder Phantomstrom, je nach Versorgungsart.

Sollte man partout keinen Adapter für das eigene Mikrofon/Smartphone auftreiben können, oder die Software auf dem Gerät keine Aufnahme mit externer Tonquelle gestatten, kann man nur noch auf externe Lösungen zurückgreifen, die die Tonspur selbst aufzeichnen und anschliessend im Videoschnitt die aufgenommene Tonspur zum Video hinzufügen.

Ich hoffe der Artikel erschlägt die meisten Fragen, die ihr zu diesem Thema habt, sollte ich Dinge vergessen haben oder noch Fragen offen sein, dann lasst es mich wissen und schreibt die Frage in die Kommentare. Sollte euch der Artikel geholfen haben, dann wäre es nett wenn ihr ihn teilt, mit einem +1 verseht oder was auch immer, das hilft Anderen diesen Artikel besser zu finden.

Videotipps zum Galaxy Note: S-Pen, USB- und HDMI-Adapter

Das Galaxy Note hat viel zu bieten, allen voran den S-Pen getauften Stylus, sowie die Möglichkeit mittels Adapter USB-Geräte oder externe Bildschirme verbinden zu können.

Damit eine Vorstellung der entsprechenden Funktionen nicht ganz so langweilig wird, habe ich diese in zwei kurze Videos gepackt, die ihr euch in Ruhe ansehen könnt und danach hoffentlich einen besseren Überblick über die Funktionen des Galaxy Notes habt.

Samsung Galaxy Note Frontansicht
Samsung Galaxy Note Frontansicht (Foto: Samsung)

Der S-Pen ist mit einem kleinen Knopf ausgestattet, der es erlaubt Gesten mit dem Stift auszuführen, die Gesten hier kurz im Überblick:

  • Drücken und nach links über das Display wischen: emuliert Funktion der Zurück-Taste
  • Drücken und nach oben über das Display wischen: emuliert Funktion der Menü-Taste
  • Drücken und Doppelklick aufs Display: ruft die Quick-Memo App auf
  • Drücken und lange auf das Display gedrückt halten: erstellt einen Screenshot und öffnet diesen im Bearbeitungsmodus

Wie das nun am „lebenden“ Objekt aussieht, könnt ihr im Video sehen:


YouTube Direktlink

Zusätzlich kann man dank MHL-Adapter das Galaxy Note mit einer USB-On the Go Funktionalität ausstatten und Speichersticks, Kartenleser und ähnliche Geräte verbinden, ausserdem ermöglicht der Adapter den Anschluss von USB-Eingabegeräten, also Mäusen und Tastaturen. Mit dem HDMI-Adapter kann das Note an ein externes Display angeschlossen werden, ob dies nun der Computermonitor oder ein grosser Fernseher ist, ist egal, solange man ihn mittels HDMI verbinden kann. Videos können in Full HD über den Ausgang des Notes ans Display übertragen werden. Gerade Spiele machen auf dem Fernseher nochmal doppelt soviel Spass. Möchte man parallel eine Maus und Tastatur nutzen, benötigt man Bluetooth Geräte die das HID Profil anbieten, denn ein paralleler Anschluss von HDMI und USB Geräten ist nicht möglich.

Erklärung und Beispiele sieht man im Video:


YouTube Direktlink

Beide Adapter kann man über Amazon beziehen, die originalen Samsung Versionen verlinke ich unter dem Artikel. Natürlich gibt es verschiedene Alternativlösungen, stellenweise zu weniger als der Hälfte des Preises. Ich habe mich für die Samsung Adapter entschieden.

Falls euch die Videos gefallen und der Artikel hilfreich war, dann lasst doch ein +1 da!

Galaxy Note und Adapter auf Amazon.de:

HowTo: Box.com unter Ubuntu mit WebDAV einbinden

Box haut im Moment ja einiges an Speicher raus, gerade in Verbindung mit verschiedenen Herstellern und deren Aktionen. Schnell können es 50GB sein, die man unkompliziert als stolzer Besitzer eines LG, Sony Ericsson usw. Gerätes einheimsen kann.

Ja, ich weiss, man kann sich den zusätzlichen Speicher auch erschleichen, genügend Blogartikel dazu gibt es im Netz. Ich habe bewusst darauf verzichtet, denn mit solchen Aktionen schadet ihr den Anbietern und am Ende euch selbst, weil es die Dienste vielleicht schon bald nicht mehr gibt, da sie sich nicht mehr finanzieren können, oder sie lassen in den Qualität nach, da die Mischkalkulation nicht mehr klappt.

Das musste einfach mal gesagt werden, denn genau in solchen Momenten geht mir die „wir wollen alles kostenlos“-Mentalität sehr gegen den Strich, da man sich letztendlich immer nur selbst schadet, bei solchen Vorteilserschleichungen.

Wer nun seinen Box Account bequem im Ubuntu Dateimanager eingebunden haben möchte und sich den Weg und Zugriff über die Webseite ersparen will, der kann sich mittels WebDAV mit dem Box-Server verbinden:

Ubuntu Box.com WebDAV Einrichtung
Ubuntu Box.com WebDAV Einrichtung
  1. Auf „Datei -> Mit Server verbinden“ gehen
  2. Im folgenden Bildschirm die entsprechenden Einstellungen (Server muss dav.box.com/dav lauten, Stand 18.09.2014!) auswählen
  3. Für Benutzername und Passwort die entsprechenden Box.com Accountdaten nutzen
  4. Auf „Verbinden“ drücken
Anschliessend öffnet sich automatisch der Dateimanager und zeigt euren Box-Account an. Man kann nun Daten hin und her kopieren und Box.com fast wie einen lokalen Ordner nutzen.
Sollte dieser kleine Tip für euch nützlich gewesen sein, dann sagt es doch weiter, vielleicht hilft er auch anderen Nutzern!

Nginx konfigurieren und PHP als FastCGI bereitstellen

Teil 3 unserer kleinen HowTo-Reihe. Wir zeigen euch, wie man eine WordPress Webseite mit Nginx auf Ubuntu Server beschleunigen kann. Nachdem wir Nginx bereits installiert haben und PHP und MySQL, wird nun erklärt, wie man ein reibungsloses Zusammenspiel konfiguriert. [sws_divider_top]Bevor ich nun erkläre wie man PHP in Nginx einbindet, müssen wir ersteinmal wissen, wie die Nginx Konfiguration funktioniert. Die Konfiguration hat eine feste, logische Struktur:

# Hier werden nur Einstellungen vorgenommen die ganz global sind # wie z.b. der User, womit nginx ausgeführt werden soll
befehl;
befehl;

events {
  # hier kann einstellt werden wie nginx mit Verbindungen umgeht
  befehl;
}

http {
  # Einstellungen für den http Server
  befehl;
  befehl;
  include conf/mime.types; # Einstellungen aus anderer Datei dazuholen 

  server {
    # Einstellungen für einen Host
    listen nodch.de; # dieser Serverbereich gilt für die domain nodch.de
    befehl;
    befehl;

    location / {
      # Einstellungen für das Root Verzeichnis 
      befehl;
    }

    location /download/ {
      # Einstellungen für /downloads
      befehl;
    }

    location ~* ^.+\.(jpg|jpeg|gif)$ {
      # Einstellungen für alle URLs die auf .jpg, .jpeg oder .gif enden
      befehl;
    }
  }
}

Der server und der location Bereich kann beliebig oft vorkommen, solange er an der richtigen Sstelle ist. Einige Befehle können nur in definierten Bereichen stehen. Ich werde euch hier die wichtigsten Funktionen für jeden Bereich erklären.

Globale Einstellungen

user             www www;             # nginx wird als User www in der Gruppe www ausgeführt 
worker_processes 2;                   # nginx wird 2 Verarbeiter Prozesse starten
pid              /var/run/nginx.pid;  # pid file wird dort gespeichert

Außerdem kann noch der error_log definiert werden, jedoch separiere ich diese immer in die einzelnen Server.  Wird sie oben angegeben, sieht man im log auch globale Fehler. Eine komplette Auflistung aller globalen Einstellungen findet man im Nginx Wiki#NginxHttpMainModule. Mit worker_processes und dem event Bereich könnt ihr die Performance des Servers beeinflussen. Der event Bereich lässt verschiedene Einstellungen zu, der Wichtigste ist aber:

worker_connections 1024;

Wenn ihr worker_proesses * worker_connections rechnet, erhaltet ihr die maximale Anzahl gleichzeitiger Clients, im Beispiel also maximal 2048. Auch hier findet ihr wieder alle möglichen Einstellungen im Nginx Wiki#NginxHttpEventsModule.

Die richtige Wahl der worker_processes ist wichtig! Wollt ihr eine Webseite haben, die sehr Last intensiv ist, also mit SSL und GZIP, so sollte die Zahl der Worker Prozesse nicht die Anzahl der CPU Cores übersteigen. Verwendet ihr den Server aber als Host für statischen Content, kann die Zahl erhöht werden, um einen schnellstmöglichen Dateizugriff zu haben.

HTTP Server Einstellungen

Alle hier getätigten Einstellungen wirken sich direkt auf die eingetragenen server Bereiche aus. Im http Bereich werden in der Regel Einstellungen gemacht, die für alle server Bereiche gleich sind, wie beispielsweise das access log format, oder gzip. Diese Befehle können problemlos im server Bereich überschieben werden. Hier seht ihr wie der http Bereich bei nodch.de aussieht:

include /etc/nginx/mime.types;

log_not_found off; # kein Status 404 logen
                   # Log format soll Apache ähnlich sein
log_format main	'$remote_addr - $remote_user [$time_local] "$request"'
 ' $status $body_bytes_sent "$http_referer" "$http_user_agent"';

sendfile           on;  # Erlaubt sendfile(). Infos hier
tcp_nodelay        on;  # Für sendfile()
keepalive_timeout  6;   # Verbindungen früh wieder schließen
server_tokens      off; # Versionsnummer nicht auf der Fehlerseite zeigen

gzip               on;    # GZip Anschalten
gzip_http_version  1.0;
gzip_comp_level    2;     # Kompressionslevel. Performancesache
gzip_proxied       any;   # Proxy Verhalten
gzip_min_length	   1100;  # erst ab 1100 byte größe kompremieren
gzip_buffers       16 8k;
# Folgende Dateitypen kompremieren
gzip_types         text/plain text/html text/css application/x-javascript
                   application/xml application/xml+rss text/javascript;
gzip_disable       "MSIE [1-6].(?!.*SV1)"; # GZip für den IE6 auschalten
gzip_vary          on;  # Vary Header senden

# server und zusatzconfigs einbinden
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

Dies ist eine vergleichsweise simple Konfiguration, wir definieren, das wir immer GZip benutzen wollen, jedoch nicht für den IE6. Außerdem setzen wir das keepalive_timeout stark runter, um erhöhtes Trafficaufkommen problemlos zu verarbeiten. Außerdem ändern wir das Log Format in das von Apache, um Analyse Tools zu benutzen. Eine Auflistung aller Core Befehle gibt es auch wieder im Nginx Wiki#NginxHttpCoreModule sowie eine Übersicht über alle anderen Module. Viel wichtiger als der http Bereich, ist für uns aber der server Bereich.

Der server Bereich ist ähnlich dem VirtualHost Eintrag im Apache. Hier ein Beispiel:

server {
  server_name  nodch.de; # Dieser Bereich ist nur für die Domain nodch.de   # nodch.de wird auf www.nodch.de umgeschrieben
  rewrite ^(.*)	https://nodch.de$1 permanent;
}

server {
  listen        80; # Port 80 benutzen   # Dieser Bereich gilt für diese beiden Domains
  server_name   www.nodch.de photo.nodch.de; 

  root          /var/www/nodch.de/httpdocs; # Hier liegen die Dateien
  # Log hier schreiben und dabei das "main"-Format benutzen
  access_log    /var/www/nodch.de/logs/access.log  main;
  # Die Fehler landen in dieser Datei
  error_log     /var/www/nodch.de/logs/error.log;

  # die index Datei ist index.php wenn nicht da index.html ... usw.
  index         index.php index.html index.htm;
}

Wenn nun eine [sws_highlight hlcolor=“fbfac7″]index.html[/sws_highlight] Datei in [sws_highlight hlcolor=“fbfac7″]/var/www/nodch.de/httpdocs[/sws_highlight]  liegt und euer Server ist gestartet, dann könnt ihr mit eurem Webbrowser darauf zugreifen und ihr werdet den Inhalt der index.html dargestellt bekommen. Nur wird es ohne weiteres nicht klappen nodch.de aufzurufen und eure Datei zu sehen 🙂 Ihr müsst es entweder auf localhost ändern oder eure eigene Domain eintragen. Aber insoweit ist Nginx konfiguriert um statischen Content zu hosten, welcher brav komprimiert wird. Im server Bereich könnt ihr eigene location Bereiche anlegen, in denen Befehle hinterlegt werden können, die eben nur an dieser location gültig sind. Hierzu ein Beispiel:

# Gilt für die Hauptseite
location / {
  # URLs probieren ob es sie gibt, letzter Eintrag ist immer Default
  try_files $uri $uri/ /index.php;
}
 # Die Datei piwik.js, egal wo sie liegt bekommt eine Cachezeit von 90 Tagen.
location ~ piwik.js$ {
  expires 90d;
}

# Das favicon interessiert uns nicht. Log aus.
location = /favicon.ico {
  access_log off;
}

# Adressen die mit wp-content, js oder css anfangen
location ~ ^/(wp-content|js|css)/  {
  expires 30d; # Cachzeit 30 Tage
  root    /var/www/nodch.de/static; # Dateien aus anderen Ordner beziehen
}

Der location Bereich kann ziemlich frei, mithilfe von Regex bestimmt werden. Mithilfe von Steuerzeichen kann außerdem bestimmt werden, wie wichtig ein location Bereich ist.

  • =   Bedeutet, dass diese location fest ist, kein Regex
  • ~   Regex ist case sensitiv
  • *~ Regex ist case insensitiv
  • ^~ Sucht ein Regex, hört an dieser location auf wenn gefunden

Genauere Infos erhaltet ihr natürlich wieder im Nginx Wiki#location, auch sind die default Konfigurationen gut kommentiert, sodass man damit auch gleich loslegen kann.[sws_divider_top]

PHP einbinden

Mit dem vorherigen Artikel habt ihr schon PHP installiert und als FastCGI Anwendung auf 127.0.0.1:9000 gespawnt. Um diese nun mit nginx anzusteuern, müssen zwei kleine Modifikationen vorgenommen werden. Öffnet zuerst die Datei [sws_highlight hlcolor=“fbfac7″]/etc/nginx/fastcgi_params[/sws_highlight] . Der Inhalt sollte so aussehen:

fastcgi_param	QUERY_STRING		$query_string;
fastcgi_param	REQUEST_METHOD		$request_method;
fastcgi_param	CONTENT_TYPE		$content_type;
fastcgi_param	CONTENT_LENGTH		$content_length;

fastcgi_param	SCRIPT_FILENAME		$document_root$fastcgi_script_name;
fastcgi_param	SCRIPT_NAME		$fastcgi_script_name;
fastcgi_param	REQUEST_URI		$request_uri;
fastcgi_param	DOCUMENT_URI		$document_uri;
fastcgi_param	DOCUMENT_ROOT		$document_root;
fastcgi_param	SERVER_PROTOCOL		$server_protocol;

fastcgi_param	GATEWAY_INTERFACE	CGI/1.1;
fastcgi_param	SERVER_SOFTWARE		nginx/$nginx_version;

fastcgi_param	REMOTE_ADDR		$remote_addr;
fastcgi_param	REMOTE_PORT		$remote_port;
fastcgi_param	SERVER_ADDR		$server_addr;
fastcgi_param	SERVER_PORT		$server_port;
fastcgi_param	SERVER_NAME		$server_name;

Es ist wichtig, dass in SCRIPT_FILENAME der absolute Pfad verwendet wird, denn dieser wird an die PHP Worker gegeben. Würde ein vermeindlich relativer Dateipfad übergeben werden, wie z.B. [sws_highlight hlcolor=“fbfac7″]/wordpress/index.php[/sws_highlight], werdet ihr die Fehlermeldung No input file specified bekommen. Er muss also absolut sein: [sws_highlight hlcolor=“fbfac7″]/var/www/prad/zu/index.php[/sws_highlight].

Ist diese Anpassung gemacht, öffnet bitte die Datei, in der ein server Bereich vorhanden ist. Fügt eine neue location hinzu:

location ~ \.php$ {
  include                  fastcgi_params; # Parameter einbinden
  fastcgi_pass             127.0.0.1:9000; # Anfrage an Worker weitergeben
  fastcgi_index	           index.php; # Standard Dateiname
  fastcgi_split_path_info  ^(.+\.php)(/.+)$; # Parameter abtrennen
  fastcgi_intercept_errors on; # Fehler ausgeben
}

Diese location bezieht sich auf alle PHP Dateien und reicht die Verarbeitung an unsere PHP Worker weiter. Die Parameter werden von der URL abgetrennt, was bewirkt, das auch URL Parameter an PHP gegeben werden und normal benutzt werden können. Alternativ zu 127.0.0.1:900 kann auch ein Unix-Socket verwendet werden. Dazu im Startscript einfach nicht die Adresse 127.0.0.1:9000 sondern eine Datei wie [sws_highlight hlcolor=“fbfac7″]/var/socket/php.socket[/sws_highlight]  binden. Danach muss der Parameter fastcgi_pass angepasst werden:

fastcgi_pass unix:/var/socket/php.socket;

Das wars auch schon. Ihr könnt jetzt folgendes testen:

$ echo "<?php phpinfo(); ?>" > /var/www/eure/httpdocs/info.php

Dann einfach die info.php im Browser aufrufen und ihr werdet die PHP Konfigurationswebseite sehen!

Viel Spaß beim testen! Im nächsten Teil dieser Serie werde ich euch dann zeigen, wie ihr WordPress auf einer Nginx Umgebung benutzt und es mit Hilfe von W3TotalCache, sowie anderen Optimierungsmethoden spürbar schneller machen könnt.

[sws_divider_top] Teil 0: Einführung
Teil I: Installation der aktuellen Nginx-Version auf Ubuntu
Teil II: Installation von MySQL und PHP
Teil III: Nginx konfigurieren und PHP als FastCGI bereitstellen
– Alternativ: PHP-FPM Installieren und bereitstellen (folgt !)
Teil IV: Nginx für WordPress optimieren

HowTo: Installation von MySQL und PHP auf Ubuntu Server

In einer kleinen HowTo-Reihe zeigen wir euch, wie man eine WordPress Webseite mit Nginx auf Ubuntu Server beschleunigen kann. Die Installation von MySQL und PHP ist Teil 2 der Reihe.  MySQL und PHP sind ebenso einfach Installiert wie Nginx selbst.

MySQL-logo

[sws_divider_top]Fangen wir mit dem Einfacheren an: MySQL.

Ein einziger Befehl reicht aus im MySQL vollständig zu installieren:

$ sudo apt-get install mysql-server mysql-client

Theoretisch kann der MySQL Server jetzt schon gestartet werden. Ich möchte euch jedoch noch etwas über dessen Konfiguration erzählen. Ihr findet die Konfigurationsdatei unter [sws_highlight hlcolor=“fbfac7″]/etc/mysql/my.conf[/sws_highlight]. Diese kann mittels Dateieditor einfach geöffnet und editiert werden. Wie schon erwähnt, ist diese Konfiguration normalerweise ausreichend. Jedoch sollte man über folgende Einstellungen bescheid wissen:

datadir        = /var/lib/mysql

Im datadir werden die Datenbanken im Filesystem gespeichert. Sollte der Fall eintreten, dass der MySQL Server nicht mehr gestartet werden kann, könnt ihr hier die Daten retten. Dies geht leider nur wenn als Datenbankengine MyISAM gewählt wurde (Ist bei WordPress der Fall). Wurde eine andere Engine wie InnoDB gewählt, erfordert es Glück oder einen großen Aufwand diese Daten noch zu retten.

bind-address        = 127.0.0.1

Über die bind-address wird geregelt über welche IP Adresse der Server erreichbar ist. Standardmäßig steht diese Einstellung auf 127.0.0.1, sprich der Server ist nur von localhost erreichbar. Wählt ihr eure öffentliche Server IP so könnt ihr, wenn ihr euch das Recht eingeräumt habt, auch von extern zugreifen.

key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
#max_connections = 100
#table_cache = 64
#thread_concurrency = 10
query_cache_limit = 2M
query_cache_size = 32M

Mit diesen Einstellungen kann die meiste Performance aus dem Server geholt werden, oder auch vernichtet werden. Ihr könnt alle Cachegrößen und Verbindungen definieren. Ich werde jetzt nicht auf die Optimierung von MySQL eingehen, diese Einstellungen reichen aus, um einen korrekt arbeitenden MySQL Server zu betreiben. Wer möchte kann aber gern in der offiziellen Dokumentation nachschauen: Kapitel 7: Optimierung

[sws_divider_top]PHP-logoDie PHP Installation ist auch nicht viel schwerer. Da wir jedoch die aktuellste PHP Version benutzen wollen, müssen wir vorher noch neue Repositories eintragen, denn in den offiziellen Apt-Quellen ist noch eine ältere Version enthalten.

$ sudo echo "deb http://ppa.launchpad.net/nginx/php5/ubuntu lucid main" >> /etc/apt/sources.list
$ sudo echo "deb-src http://ppa.launchpad.net/nginx/php5/ubuntu lucid main" >> /etc/apt/sources.list

Wenn wir das erledigt haben starten wir auch schon die Installation:

$ sudo apt-get install php5 php-pear php5-dev php5-suhosin php5-mysql libpcre3-dev php5-cgi

Dieser Befehl installiert die neue Version von PHP, zusätzlich wird noch PEAR installiert. Mit PEAR können offizielle PHP Pakete wie apc oder memcache nachinstalliert werden. Für eine Nachinstallation muss PHP kompiliert werden, dafür installieren wir das PHP Dev Paket gleich mit. Dazu kommen dann noch der Suhosin Patch, MySQL Unterstützung, Abhängigkeiten und der CGI Modus…

Die Installation wird etwas länger dauern als bei Nginx und MySQL.

Da wir PHP über FastCGI anbinden wollen, müssen wir die PHP Worker noch spawnen, die geschieht über den Befehl:

$ php-cgi -b 127.0.0.1:9000

Alle PHP Worker lauschen nun auf Port 9000, damit man das nicht jedes mal neu eingeben muss, gibt es im Nginx Wiki ein simples Linux-Style-Start-Script:

#!/bin/bash
BIND=127.0.0.1:9000 # Eure Worker werden hier lauschen
USER=www-data # Bitte den selben Nutzer angeben wie in Nginx, default ist www-data
PHP_FCGI_CHILDREN=15
PHP_FCGI_MAX_REQUESTS=1000

PHP_CGI=/usr/bin/php-cgi
PHP_CGI_NAME=`basename $PHP_CGI`
PHP_CGI_ARGS="- USER=$USER PATH=/usr/bin PHP_FCGI_CHILDREN=$PHP_FCGI_CHILDREN PHP_FCGI_MAX_REQUESTS=$PHP_FCGI_MAX_REQUESTS $PHP_CGI -b $BIND"
RETVAL=0

start() {
 echo -n "Starting PHP FastCGI: "
 start-stop-daemon --quiet --start --background --chuid "$USER" --exec /usr/bin/env -- $PHP_CGI_ARGS
 RETVAL=$?
 echo "$PHP_CGI_NAME."
}
stop() {
 echo -n "Stopping PHP FastCGI: "
 killall -q -w -u $USER $PHP_CGI
 RETVAL=$?
 echo "$PHP_CGI_NAME."
}

case "$1" in
 start)
   start
 ;;
 stop)
   stop
 ;;
 restart)
   stop
   start
 ;;
 *)
   echo "Usage: php-fastcgi {start|stop|restart}"
   exit 1
 ;;
esac
exit $RETVAL

Speichert Script am besten unter [sws_highlight hlcolor=“fbfac7″]/etc/init.d/[/sws_highlight] mit dem Namen [sws_highlight hlcolor=“fbfac7″]php-fcgi[/sws_highlight], dann könnt ihr ganz einfach einen Autostart einrichten:

$ sudo update-rc.d php-fcgi defaults

Nun fehlen nur noch apc und memcache:

$ sudo pecl install memcache
$ sudo pecl install apc

Die Installation sollte eigentlich korrekt ablaufen, es kann aber passieren, dass PEAR eure php.ini nicht findet, wenn das der Fall ist, einfach diese Zeilen in die Datei [sws_highlight hlcolor=“fbfac7″]/etc/php/cgi/php.ini[/sws_highlight]eintragen:

extension=memcache.so
extension=apc.so

Da sind wir auch schon fertig!  Im nächsten Kapitel werde ich euch zeigen wie ihr alles zusammenklebt, PHP als FastCGI Anwendung im Nginx bereitstellt und wie man Nginx richtig konfiguriert.

[sws_divider_top] Teil 0: Einführung
Teil I: Installation der aktuellen Nginx-Version auf Ubuntu
Teil II: Installation von MySQL und PHP
Teil III: Nginx konfigurieren und PHP als FastCGI bereitstellen
– Alternativ: PHP-FPM Installieren und bereitstellen (folgt !)
Teil IV: Nginx für WordPress optimieren

HowTo: Installation der aktuellen Nginx-Version auf Ubuntu

Nginx ist recht einfach installiert. Ich gehe hier von einem (frischen) Ubuntu aus. Um ein produktives High Performance System aufzubauen nimmt man am besten Ubuntu 10.04 Lucid Lynx LTS Server Version, da es die Variante mit 5 Jahren Support ist. Ich werde hier nicht erwähnen wie man Nginx selbst kompiliert, es geht rein um eine Installation aus den Apt Repositories. Loggt euch auf euren Server ein und los gehts! Dieses HowTo ist so aufgebaut, dass ihr Schritt für Schritt mitmachen könnt.

Das Nginx in den eingetragenen Repositories ist meist nicht ganz aktuell, deswegen tragen wir die nginx.org Quellen in Apt ein:

$ sudo echo "deb http://nginx.org/packages/ubuntu/ lucid nginx" >> /etc/apt/sources.list
$ sudo echo "deb-src http://nginx.org/packages/ubuntu/ lucid nginx" >> /etc/apt/sources.list

Damit die Änderungen übernommen werden reicht ein simples:

$ sudo apt-get update

Nun haben wir die aktuelle Grundlage für den Nginx Server. Die Installation ist nur noch einen Befehl entfernt:

$ sudo apt-get install nginx

Fertig! Für die Installation muss an sich noch kein Aufwand betrieben werden. Alle Konfigurationsdaten sind in [sws_highlight hlcolor=“fbfac7″]/etc/nginx[/sws_highlight] zu finden. Dort findet ihr die Datei [sws_highlight hlcolor=“fbfac7″]nginx.conf[/sws_highlight] sowie die beiden Ordner [sws_highlight hlcolor=“fbfac7″]sites-enabled[/sws_highlight] und [sws_highlight hlcolor=“fbfac7″]sites-available[/sws_highlight]. In der Datei nginx.conf befinden sich die Grundeinstellungen des Servers, dort wird definiert, dass alle Dateien aus sites-enabled geladen werden sollen. Aktive Seite haben wir in unserem Fall mit einem symbolischen Link zum Ordner sites-available verknüpft. Das ist mit folgendem Befehl schnell gemacht:

ln -s /etc/nginx/sites-available/nodch.de /etc/nginx/sites-enabled/nodch.de

Nginx ist sehr einfach zu Konfigurieren, wenn ihr möchtet könnt ich euch die Syntax der Konfiguration gerne schon einmal anschauen. Ich werde später genau auf die Konfiguration eingehen, also erst einmal weiter mit der Installation von MySQL und PHP.

[sws_divider_top]

Teil 0: Einführung
Teil I: Installation der aktuellen Nginx-Version auf Ubuntu
Teil II: Installation von MySQL und PHP
Teil III: Nginx konfigurieren und PHP als FastCGI bereitstellen
– Alternativ: PHP-FPM Installieren und bereitstellen (folgt !)
Teil IV: Nginx für WordPress optimieren

WordPress Webseite mit Nginx auf Ubuntu Server beschleunigen

Das Internet wird jeden Tag größer und schneller, und jede Webseite oder jedes Blog, das eine hohe Reichweite hat kennt das Problem: Der Traffic zwingt irgendwann den Server in die Knie. Nun steht man vor der Wahl: Hat man die finanziellen Mittel, besorgt man sich neue Hardware, denn je besser ein WebServer ist, umso mehr Anfragen kann er gleichzeitig bearbeiten. Zusätzlich kann man auch die WebSeite optimieren, also CSS Dateien zusammen fassen, Bilder in Sprites packen und wenn möglich sogar Javascript zusammentun, beziehungsweise auslagern und statischer Content kann mit einer Cache-Zeit von über 30 Tagen ausgestattet werden. Nur was ist, wenn all das absolut nicht mehr klappt?

Dies ist uns passiert, die Besucherzahlen liefen stabil nach oben und Google hat uns sehr gut platziert. Um genau zu sein auf Platz 1 der Newskategorie „Technik/Wissenschaft“, direkt in der Schlagzeilenübersicht auf der news.google.de Startseite,  was zwar wirklich toll war, nur lieferte uns Google in diesem Moment mehr als 250 Anfragen … pro Sekunde. Unser sowieso schon angeschlagener Apache2 brach gnadenlos zusammen, ohne das wir was tun konnten. Der ganze Spaß wiederholte sich noch 2 mal und wir versuchten herauszufinden warum. Ich muss dazu sagen, dass unser Server mit 2 CPUs ausgestattet ist und über 8 GB RAM verfügt und außer nodch.de nichts anderes auf der Hardware lief. Wir kamen relativ schnell zu dem Entschluss, dass Apache schuld ist. Der Server stand permanent unter Dauerlast, der Arbeitsspeicher jedoch fühlte sich unnütz. Man sollte sich also genau fragen wo Flaschenhälse sind: Hardware, Software oder die Serversoftware.

Wir haben uns dazu entschieden Apache abzusetzen und durch Nginx (gesprochen: „Engine X“) zu ersetzen. Nginx bezeichnet sich selbst als „high performance web server“ der effektiver als Apache arbeitet und dabei sogar weniger Speicher verbraucht. Installation, Einrichtung und Gebrauch sind ebenso einfach wie bei Apache.

Gängige Apache Konfigurationen sehen in der Regel immer gleich aus:

Es läuft ein Apache2 Server in mehreren Instanzen, PHP und MySQL Modul sind einkompiliert und werden als Extension geladen. Es werden vhosts definiert und größtenteils werden per .htaccess Datei spezifische Einstellungen vorgenommen.

Genau da liegt das Problem: Ist beispielsweise PHP mit einkompiliert, wird PHP bei jedem Request an den Server geladen, was unter dem Strich enorm Ressourcen nutzt. Apache wertet außerdem .htaccess Daten mit jedem Request neu aus. Jeder kann sich selbst zusammenreimen was passiert wenn da mehr als 100 Anfragen pro Sekunde reinkommen und die Hardware eher normal ist. 🙂

Nginx ist im Vergleich zu Apache jetzt nicht das Torschlagargument, aber die Unterschiede sind schon deutlich. Grade wenn es um statischen Content geht, ist Nginx um einiges schneller als Apache. PHP wird in Nginx per FastCGI angebunden, was den Vorteil hat, dass die PHP Worker gespawnt im System liegen und nur auf Arbeit warten. Nginx kann so konfiguriert werden, dass PHP nur ausgeführt werden soll, wenn es denn auch nötig ist. Apache mit FastCGI zu verwende ist zwar auch möglich, nur nutzen das leider die Wenigsten.

Ich möchte euch in einer kleinen HowTo-Reihe die Einrichtung von Nginx auf Ubuntu zeigen und erklären wie die verborgene Performance der Hardware optimal genutzt werden kann. Dabei beziehe ich mich auf eine WordPress Installation. Ich persönlich bin Begeistert vom enormen Performancesprung von nodch.de, den wir mit dieser Konfiguration erreichen konnten.

Wie das alles im Detail funktioniert, installiert und eingerichtet wird, wollen wir euch natürlich nicht vorenthalten!

[sws_divider_top]

Teil 0: Einführung
Teil I: Installation der aktuellen Nginx-Version auf Ubuntu
Teil II: Installation von MySQL und PHP
Teil III: Nginx konfigurieren und PHP als FastCGI bereitstellen
– Alternativ: PHP-FPM Installieren und bereitstellen (folgt !)
Teil IV: Nginx für WordPress optimieren

Ich versuche übrigens jeden Tag mindestens einen Artikel zu Reihe zu veröffentlichen.

Mobile BRAVIA Engine für Xperia PLAY und Xperia X10

Sony Ericsson nutzt die schon von den TV-Geräten bekannte BRAVIA Engine auch bei Smartphones, so haben viele der Android Geräte die mobile Version der BRAVIA Engine an Bord. Das Xperia PLAY und das Xperia X10 sind einige der wenigen Geräte, welche ohne die Engine auskommen müssen. Das PLAY ist, von den Leistungsdaten mit dem Xperia Arc eigentlich auf Augenhöhe, von der 5MP gegenüber der 8MP des Arcs mal abgesehen. Warum Sony Ericsson beim PLAY und X10 darauf verzichtet hat – man weiss es nicht.

Was macht die mobile BRAVIA Engine überhaupt?

Die BRAVIA Engine an sich versucht über verschiedene, softwareseitige Anpassungen, die subjektive Qualität eines Bilder oder Videos zu verbessern. Hierzu bedient man sich einiger Dinge:

  • Verminderung von Rauschen im Bild
  • Erhöhung der Bildschärfe durch Nachschärfung
  • Farbanpassung durch Erhöhung der Sättigung
  • Steigerung des Kontrastes

Bilder werden also nachgeschärft und Kontraste, durch eine leichte S-Kurven Anpassung, erhöht. Farben bekommen mehr Sättigung und wirken somit „lebendiger“, sowie einer Verringerung des Bildrauschens. Ein paar dieser Anpassungen werden durch die BRAVIA Engine sehr aggressiv vorgenommen und an einem PC Bildschirm, mit einer grösseren Fläche würde man das Bild sicher nicht mehr „schön“ finden, da man Artefaktbildungen erkennen kann, Entrauschte Bereiche zu flach werden, oder durch die Kontrastkurve dunkle Bereich zu dunkel und helle Bereiche überstrahlt wirken. All das funktioniert auf den kleinen Touchscreens der Smartphones aber durchaus gut und verbessert das subjektive Bildempfinden. Sony Ericsson stellt die Anpassungen in einem kurzen Video selbst vor, ich habe euch zwei Bilder, mit jeweils aktivierter und deaktiviert BRAVIA Engine, vom Smartphone per Screenshot aufgenommen (Klick für grössere Ansicht), angehangen. Man sieht die Farbanpassung und die Kontrastkurvenänderung sehr gut.

Screenshot BRAVIA Engine aus
Screenshot BRAVIA Engine aus
Screenshot BRAVIA Engine an
Screenshot BRAVIA Engine an

Wie bekommt man die mobile BRAVIA Engine auf das Xperia PLAY oder das Xperia X10?

zdzihu und DooMLoRD haben im Forum der XDA Developer zwei aus dem Arc entnommene Dateien zur Verfügung gestellt und erklären die Anpassungen, die auf dem PLAY und X10 vorzunehmen sind, damit man die mobile BRAVIA Engine aktivieren, bzw. deaktivieren kann. Voraussetzung dafür ist ein gerootetes Gerät, wie bei den meisten Änderungen dieser Art. Es ist hierbei unerheblich ob das Gerät einen entsperrten Bootloader hat, oder nicht.
Nach Download der Zip-Datei kann man diese über ein funktionierendes Recovery einspielen, oder man wählt den manuellen Weg und passt die Daten mittels Root Explorer oder ähnlicher Dateiverwaltungsprogramme an.
Die entsprechenden Anleitungen gibt es in beiden Threads bei den XDA Developern, ich habe diese hier als Quellen verlinkt. Prinzipiell steht dahinter jeweils das gleiche Prinzip:

  • Es werden beide Dateien (BE für Fotos und BE für Videos) auf das PLAY kopiert
  • nach /system/etc verschoben
  • die build.prop angepasst und um folgende zwei Zeilen ergänzt:

ro.service.swiqi.supported=true
persist.service.swiqi.enable=1

  • Sowie die Dateiberechtigungen (0755) und der Benutzer (root.root/0.0) angepasst

Danach kann das Gerät gebootet werden und die mobile BRAVIA Engine unter Einstellungen -> Display aktiviert werden.

Screenshot mobile BRAVIA Engine aus
Screenshot BRAVIA Engine aus
Screenshot mobile BRAVIA Engine an
Screenshot BRAVIA Engine an

Die mobile BRAVIA Engine optimiert nur bei Bildern in der Galerie, sowie Videos. Nach optischen Verbesserungen in anderen Bereichen muss man nicht suchen, das wird ohne Erfolg bleiben. Zwar sind es nur kleine Anpassungen, die das Bild aber spürbar verbessern, wie ich finde.

Was haltet ihr von der BRAVIA Engine? Lasst es uns wissen!

HTC Flyer Update 2.00.405.3 Schritt 1

HTC Flyer Perfomance Update (kein Android Honeycomb)

Heute kam das HTC Flyer in der 3G Version für einen Test ins Haus und wir zäumen das Pferd einmal von hinten auf, denn just nach dem Einschalten meldete sich das Flyer mit dem aktuellen Systemupdate 2.00.405.3, welches in Hinsicht der Leistung optimiert sein soll.

Das HTC Flyer wird mit Android 2.3.3 Gingerbread ausgeliefert, das aktuelle Update ist kein Update auf Android Honeycomb, sondern soll die Leistung verbessern. Eines vorweg: Messbar ist diese Optimierung nicht, das Flyer bringt in allen Benchmarks, die ich haben laufen lassen (Quadrant: 1975 Punkte, Linpack: 56.836 MFLOPS, Neocore: 51.1 FPS und Smartbench 2011: 1495 PI und 2199 GI) im Groben identische Werte.

Eine Verbesserung der allgemeinen Systemleistung will ich nicht bescheinigen, dafür hatte ich das Flyer vor dem Update zu kurz in der Hand, als hierzu eine Aussage tätigen zu können.

Der erste Testbericht zum Flyer folgt in den kommenden Tagen, hier nun erstmal die Anleitung für das OTA Update auf Systemversion 2.00.405.3 (Auf die Bilder klicken um sie in voller Grösse zu sehen):

Das Flyer begrüßt euch mit der Meldung das ein Systemupdate zur Verfügung steht, hier könnt ihr auswählen über welche Datenverbindung ihr das Update herunterladen wollt. Wie immer ist die WLan/Datenkabelverbindung zu bevorzugen:

HTC Flyer Update 2.00.405.3 Schritt 1Den Beginn des Downloads muss man mittels Druck auf OK bestätigen und dann kann es schon losgehen:

HTC Flyer Update 2.00.405.3 Schritt 2Nach erfolgreichem Download kann man das Update installieren, sich entscheiden die heruntergeladenen Daten später zu installieren oder sie verwerfen. Mit einem Klick auf OK und Jetzt installieren startet der Updateprozess. Das Flyer startet hierzu neu, installiert das Update und bootet anschliessend wieder ins System:

HTC Flyer Update 2.00.405.3 Schritt 3Nach dem Start ins System meldet sich das Flyer mit der Meldung dass das Update erfolgreich war und zeigt euch an, dass die nun installierte Version 2.00.405.3 ist:

HTC Flyer Update 2.00.405.3 Schritt 4Ab diesem Punkt ist das Flyer wieder einsatzbereit und das Update (des Handys…) abgeschlossen.

Gibt es HTC Flyer Besitzer, die das Gerät länger in der Hand hatten als ich und die der Meinung sind dass die Performance besser ist, als vor dem Update?

SIP/VoIP Konfiguration unter Android Gingerbread 2.3

Kostenlose eingehende Anrufe mit Android Gingerbread 2.3 und SIP/VoIP

SIP/VoIP Konfiguration unter Android Gingerbread 2.3
SIP/VoIP Konfiguration unter Android Gingerbread 2.3

Seit Android 2.3 ist die API Schnittstelle für SIP/VoIP geöffnet und man kann SIP/VoIP Provider direkt im Android System eintragen und nutzen, sowohl für eingehende, als auch ausgehende Anrufe.

Um SIP/VoIP mit Android 2.3 zu nutzen, bedarf es eines entsprechenden Anbieters, wie zum Beispiel Sipgate (Link zur kostenlosen Anmeldung im Basic Account).

Die Konfiguration auf dem Android 2.3 Gerät ist dann denkbar einfach, man muss nur die entsprechenden Daten beim SIP/VoIP Provider auslesen und eintragen.

Am Beispiel von Sipgate.de soll die Konfiguration an dieser Stelle kurz beschrieben werden.

  • Zuerst trägt man den Benutzernamen des Providers ein
  • Anschliessend das entsprechende Passwort
  • die Serverkonfiguration erfordert die Eingabe von „sipgate.de“
  • nun kann man auswählen ob der eingetrage Account das primäre Konto sein soll. Wichtig ist dies nur bei der Konfiguration mehrerer Konten, denn hier wählt man den Account, der als ausgende Nummer bei Internetanrufen gewählt wird.
  • In den optionalen Einstellungen kann man noch den Proxy konfigurieren, auch hier wird „sipgate.de“ als Proxy eingestellt.

Ab sofort ist man, sofern „Eingeh. Anrufe annehmen“ ausgewählt wurde, über die Telefonnummer des Providers erreichbar und kann ausgehend Anrufe über SIP/VoIP tätigen.

Eine zusätzliche Einstellung erlaubt es alle Anrufe über das Internet zu tätigen, bzw. vorher eine Abfrage zu erhalten über welche Weg man nach Aussen telefonieren möchte.

Die SIP/VoIP Funktion in Android 2.3 funktioniert, zumindest mit Sipgate.de reibungslos und erlaubt es, im WLan und 3G Netzwerk, qualitativ akzeptable Telefonate zu führen, ohne weitere Kosten zu verursachen. Eingehende Anrufe sind bei den entsprechenden Anbietern ohnehin kostenlos, womit das Android Gerät zu einem durchaus komfortablen Endgerät für SIP/VoIP Anrufe wird.