Streamen mit Linux

Auf dieser Seite möchte ich darüber berichten, wie ich ein Internet-Radio ausschließlich mit Linux-Rechnern betreibe. Der Aufbau ist etwas kompliziert; ich hatte einiges zu lesen, zu basteln und zu suchen, bis alles funktionierte. Hier zeige ich, was ich herausgefunden habe, und vor allem auch, mit welchen Tücken ich zu kämpfen hatte.

Die Tücken entstanden vor allem deshalb, weil ich nicht einfach Musik irgendwohin streamen, sondern „richtiges“ Radio mit Moderation machen möchte. Wenn man einfach nur eine Playlist laufen lassen will, die im LAN oder im Internet empfangen werden kann, ist alles viel einfacher.

Update 2011-12-29 Komplette Überarbeitung: Anweisungen für Debian sarge, etch und lenny raus, alles auf Debian squeeze abgestimmt, und alles gelöscht, was mit jackd zu tun hat, weil der nun wirklich nicht mehr gebraucht wird.

Streaming-Vorgang

Um die folgenden Erklärungen besser zu verstehen, ist es sinnvoll, ein bißchen was darüber zu wissen, was beim Streamen eigentlich so alles passiert.

Klangdaten (Sprache, Musik) aus verschiedenen Quellen (zum Beispiel Musikdateien, CD, Mikrofon) werden, teils mit Hilfe entsprechender Software, von der Soundkarte wiedergegeben. Währenddessen werden sie von einer weiteren Software sofort wieder als Rohdaten abgegriffen und in ein einheitliches Format gebracht („encoded“; das kann MP3 sein, aber auch OggVorbis, AAC oder FLAC). Daraus wird ein Datenstrom erzeugt, der an einen Server geschickt wird. Dieser Server fungiert als Verteiler; von dort aus können Hörer sich mit einem Player einklinken und den erzeugten Datenstrom (engl: data stream oder einfach stream) empfangen. Für den Player sieht das dann so aus, als ob er eine einzige Musikdatei abspielt, deren Größe er nicht kennt.

Hardware

Stream-PC

Beim streamenden Rechner sind zwei Komponenten entscheidend: CPU und Soundkarte. Bei aktuelleren Rechnern ist das meist kein Thema; wer aber wie ich auf überwiegend ältere Hardware zurückgreifen muss, könnte hier schnell an Grenzen stoßen.

CPU

Der Prozessor des streamenden Rechners sollte nicht weniger als 500 MHz haben. Der Grund ist das rechenaufwendige Encoden der Klangdaten von der Soundkarte in das Zielformat des Streams. Mit seinen 500 MHz hatte mein PIII schon teils heftig zu kämpfen; die CPU-Auslastung lag zwischen 80 und 90 %. Mit meinem Athlon XP1800+ komme ich immer noch auf 30 - 35 % Auslastung.

Höhere Taktraten sind insbesondere dann angeraten, wenn

Was passiert, wenn die CPU nicht leistungsfähig genug ist? Nun, dann können die Ausgangsdaten nicht schnell genug encoded werden, und es entstehen „buffer underruns“. Das heißt, der Server bekommt weniger Daten, als er senden will. Das kann soweit gehen, daß die Player der Hörer ins timeout laufen und vom Stream getrennt werden.

Wenn kein schnellerer Rechner zur Verfügung steht, kann man wohl dadurch Abhilfe schaffen, daß man zwei PCs miteinander verbindet und die Aufgaben verteilt. PC #1 spielt dann die Daten auf seiner Soundkarte ab. Ein Kabel verbindet Line-Out dieser Soundkarte mit Line-In der Soundkarte in PC #2. Dieser kümmert sich um das Encoden und sendet an den Server. Auf diese Weise sollen pro PC 350 bis 400 MHz genügen; ich habe das allerdings selbst noch nicht ausprobiert.

Soundkarte

Nicht jede Soundkarte ist auch zum Streamen geeignet! Bei mir funktionieren folgende Karten:

Ich hatte es bei dem PIII tagelang mit der onboard-Soundkarte, einer ESS Solo1 1938, probiert, um dann bei einer Google-Recherche zu erfahren, daß das alles keinen Zweck hat.

Eine Soundkarte zum Streamen muß nämlich unbedingt Vollduplex können. Der Grund ist wieder das Abgreifen der Klangdaten von der Karte: Dafür wird ein „Rückkanal“ benötigt. Die ESS Solo1 hat sowas einfach nicht. Egal ob man also eine der oben genannten Karten benutzt oder eine andere: Sie muß Vollduplex beherrschen, sonst kann man sie nicht einsetzen. Ich habe eine C-Media 8738 bekommen, das funktioniert einwandfrei. Und so nebenbei klingt sie auch wesentlich besser als die ESS Solo1.

Allerdings gibt es mit der C-Media wieder ein anderes Problem: Ein Mono-Mikrofon hört man lokal zwar auf beiden Kanälen, aber die encodeten und gestreamten Klangdaten vom Mikrofon kommen bei den Hörern nur noch auf einem Kanal an. Das kann bei Sendungen mit größerem Redeanteil sehr störend sein.

Mikrofon bzw. Headset

Ein richtig gutes Mikrofon ist natürlich schick; allein, ich kann mir keines leisten. Ich habe derzeit ein billiges Logitech-Mikrofon in Betrieb. Das tut es zumindest für den Anfang auch; Hörer bemängelten nur, daß das Mikrofon auch bei höchster Sendeleistung, und obwohl ich es sehr dicht vorm Mund hatte, etwas zu leise sei. Mittlerweile bin ich bei einem einfachen Logitech-Mikrofon, das die gleichen Probleme zeigt; billig ist halt billig.


Server

Der Server, der wie gesagt einfach nur ein Verteiler ist, braucht vor allem eine „dicke“ Leitung. Er muß die Daten vom Stream-Rechner entgegennehmen und an die gewünschte Anzahl Hörer wieder parallel raussenden können. Bei zwei Hörern mag das vielleicht noch über eine DSL-Leitung gehen; wenn es mehr sind, sollte es schon ein Rechner mit Standleitung sein.

Ansonsten vermute ich, daß der Server nicht zu wenig RAM haben sollte, um die Daten zwischenspeichern zu können. Meinem alten Rootserver schienen seine 256 MB RAM aber wohl bereits zu genügen.

Vorsicht bei Traffic-Limits!

Das einzige ernsthafte Problem, das hier auftauchen könnte, ist ein Traffic-Limit des Server-Providers. Wenn man eines hat und dieses überschreitet, kann es schnell teuer werden.

Ich habe ausgerechnet, daß man bei einer Bitrate von 64 kBit/s pro Hörer und Stunde mit ca. 30 MB Traffic rechnen muß. Dazu kommt der eingehende Datenstrom, also die Datenmenge, die der Stream-PC an den Server sendet. Rechenbeispiel:

Angenommen, ich sende täglich 10 Stunden lang. Dann entstehen pro Hörer (plus Stream-PC) je 10 x 30 MB Traffic pro Tag. Damit würden in einem Monat 30 x 300 MB = 9.000 MB oder 9 GB Traffic erzeugt. Rein rechnerisch und rein auf den Traffic bezogen könnte ich so mit einem Limit von 500 GB locker 50 Hörer versorgen (500 GB / 9 = 55,55) – davon ausgehend, daß auf dem Server sonst keine traffic-relevanten Dienste laufen.


Software

Zum Streamen unter Linux ist, wenn man moderiertes Internet-Radio machen möchte, ein kleines Konglomerat an Software erforderlich. Es gibt zwar auch fertige Pakete, aber dabei lernt man ja nichts. ;-) – abgesehen davon, daß sich diese Pakete bei mir größtenteils gar nicht zum Installieren überreden lassen wollten und das einzige, das ich installiert bekommen habe, eine für mich völlig unverständliche Oberfläche mitbringt.

Stream-PC

Derzeit installiert ist Debian GNU/Linux 6.0 Squeeze. Im Gegensatz zu früheren Installationen baue ich den Kernel mittlerweile nicht mehr selbst, weil der Distributionskernel alles mitbringt, was ich brauche.

Was wird benötigt?

So, und jetzt dröseln wir das mal in die nötigen Pakete auf. Für die nächsten Schritte muß man root sein! Zuerst ist es notwendig, in /etc/apt/sources.list eine zusätzliche Paketquelle einzutragen:

deb http://www.debian-multimedia.org $distri main

In diesem Fall steht $distri für squeeze oder stable. Nach diesem Eintrag kann man einen Teil der benötigten Pakete direkt mit apt-get ziehen, und zwar:

$ apt-get install alsa-utils aumix-gtk lame audacious darksnow

Die nötigen Libs werden nachgezogen und sind hier nicht extra aufgeführt; statt audacious kann, wie erwähnt, ein beliebiger anderer Player gewählt werden. Wer einen Teil der Pakete schon installiert hat, kann diese natürlich hier rauslassen.

darksnow zieht automatisch das (nur OGG-fähige) Paket darkice nach; daher ist es für einen MP3-Stream immer noch sinnvoll, darkice zusätzlich selbst zu bauen. Das liegt daran, daß MP3 kein freies Format ist und daher von Software in Debian nicht erzeugt werden darf. Wer nur in OGG Vorbis streamen will, kann sich diese Zusatzarbeit natürlich sparen.

darkice compilieren

Wenn man sich den Tarball für darkice heruntergeladen hat, kann man die Sourcen noch lange nicht compilieren. Zunächst werden nämlich einige development files von libraries benötigt, ohne die darkice nicht gebaut werden kann.

Ich war hier insbesondere über einen Bug in der Version 0.17.1 von darkice gestolpert, die mir beim ./configure bestätigte, daß alle benötigten Dateien vorhanden seien. Tatsächlich fehlte aber eine Datei, die darkice zur Kommunikation mit jackd benötigt. In der Version 0.18.1 war dieser Bug dann behoben.

Also, erstmal devel-files „nachladen“:

$ apt-get install libasound2-dev libmp3lame-dev

Jetzt kann es losgehen: Erst noch in das Verzeichnis wechseln, in welchem der Tarball steht (ich nehme dafür meist /usr/src/ bzw. verschiebe Tarballs dorthin). Dann:

$ tar -xzf darkice-0.18.1.tar.gz

$ cd darkice-0.18.1

$ ./configure --with-alsa --with-lame

$ make

$ make install

Die Versionsnummer ist natürlich nur ein Beispiel, die 0.18.1 ist nicht mehr aktuell.

Wenn beim ./configure Warnhinweise auftauchen, fehlt was. Am besten findet man das entsprechende Paket mit apt-cache search auf das, was er als fehlend bemängelt, und dev. Wird also beispielsweise lame als fehlend angezeigt, hilft wahrscheinlich ein

$ apt-cache search lame dev

Es fehlt also dann nicht das eigentliche Paket, sondern die dazugehörigen development files.


Server

Hier ist alles viel einfacher:

$ apt-get install icecast2

… und die Installation ist gegessen.


Konfiguration

Zur Konfiguration sämtlicher Programme habe ich überwiegend das XBox360-HowTo aus dem Gentoo-Wiki genutzt, vielen Dank an den Autor!

(Die Bilder sind aus den Sarge-Versionen; die Fenster unterscheiden sich manchmal in neueren Versionen, aber eigentlich nur in der Anordnung, und auch nur minimal.)

darkice mit darksnow konfigurieren

Der erste Kandidat ist darkice. Dazu startet man darksnow und trägt dort ein paar Angaben ein (anklicken zum vergrößern):

„radio.meinserver.de“ muss natürlich durch den echten Namen (oder die IP) des Stream-Servers ersetzt werden.

Am meisten zu schaffen machte mir der Begriff Mount Point. Denn eigentlich verstehe ich darunter ein Verzeichnis in meinem Verzeichnisbaum, in welches ich ein Medium (bzw. ein Filesystem) einklinken (mounten) kann. Schließlich kam ich auf den Trichter: Das ist einfach ein Dateiname, den der Server den Playern anbieten kann, weil die einen benötigen. Denn den Playern wird ja der Stream wie eine Datei übergeben. Das wird aber nirgendwo erklärt oder auch nur erwähnt!

Das Paßwort muß natürlich mit dem in der icecast2-Konfiguration auf dem Server (siehe weiter unten) übereinstimmen.

Wenn der Stream-PC und/oder der Server genügend Plattenplatz anbieten, kann man sich von den Sendungen einen Dump (Mitschnitt) anlegen lassen. Dann wird die gesamte Sendung in eine Datei im Zielformat des Streams gespeichert. Auf dem PIII hatte das bei mir nie funktioniert, der Athlon packt es inzwischen (vermutlich auch deshalb, weil die Musikdateien mittlerweile auf einer SATA- und nicht mehr auf einer IDE-Platte liegen). Auf dem Server tut es bei mir nicht; möglicherwiese kann icecast2 das nicht, oder es fehlt noch etwas.

Im zweiten Reiter wird unter anderem die Bitrate festgelegt. Sie bestimmt primär über die Qualität des Streams, aber auch über die benötigte Bandbreite auf den Leitungen.

Der letzte Eintrag in diesem Reiter, „Device input“, muß nur für jackd wie abgebildet „jack_auto“ heißen. Wenn ohne jackd gearbeitet wird, wird hier „hw0,0“ eingetragen (davon ausgehend, daß bei mehreren vorhandenen Soundkarten die erste zum Streamen gewählt wird).

Bei der Stream-Beschreibung im dritten Reiter ist man recht frei (der Servername muß nur stimmen). Ein rechtlich relevanter Eintrag ist aber der letzte: Ich habe meinen Stream auf nicht öffentlich gesetzt, weil ich sonst GEMA-Gebühren bezahlen und mich nach deren ziemlich kruden Regeln richten müßte. Statt dessen gebe ich die Adresse für den Stream nur gezielt an Freunde, die ich mithören lassen möchte.

Am Ende nicht vergessen, die Config abzuspeichern, darksnow macht das nicht von allein. Etwas störend ist auch, daß darksnow diese Config auch beim Start nicht wieder automatisch lädt, das muß man jedesmal von Hand machen.

icecast2 konfigurieren

Ich sollte vielleicht erwähnen, daß der icecast2 nicht nur ein reiner Streamserver ist. Er bringt auch noch einen kleinen Webserver mit, der ebenfalls auf Port 8000 läuft (sofern das nicht geändert wird).

icecast2 wird komplett über die Datei /etc/icecast2/icecast.xml gesteuert. Darin sind die folgenden Einträge relevant:

<limits>

<clients>20</clients>

<!-- Legt die Höchstzahl der Hörer fest -->

</limits>

 

<authentication>

<source-password>xxxxxxxxxxxx</source-password>

<!-- Muss mit dem in darkice/darksnow übereinstimmen! -->

</authentication>

 

<hostname>radio.meinserver.de</hostname>

 

<listen-socket>

<port>8000</port>

<!-- <bind-address>127.0.0.1</bind-address> -->

</listen-socket>

 

<fileserve>1</fileserve>

 

<security>

<chroot>0</chroot>

<changeowner>

<user>icecast2</user>

<group>icecast</group>

</changeowner>

</security>

Der Eintrag unter ChangeOwner bewirkt, daß der icecast2 nur mit den Rechten eines normalen Users läuft und eben nicht mit root-Rechten. Trotzdem kann er seine Logs nach /var/log schreiben. – Eine komplette icecast.xml (die aber auch angepaßt werden muß) findet sich (leider nicht mehr, 2011-02-01) im XBox360-HowTo.

Auch beim icecast2 gibt es eine kleine Stolperfalle: Die Rechte der Dateien in /etc/icecast2/web/ müssen auf 755 geändert werden, sonst bekommen Seitenbesucher einen 404.


Stream ab!

… oder der kürzeste Computerwitz aller Zeiten: „Müßte laufen“ …

Als erstes muß natürlich der icecast2 auf dem Server laufen. Er wird – von root – gestartet mit

$ icecast2 -c /etc/icecast2/icecast.xml -b

Das -b bewirkt, daß icecast2 in den Hintergrund geht und die Konsole wieder freiräumt.


Stream-PC startklar machen

Als erstes spreche ich hier nochmal die CPU-Leistung an. Ich hatte beim PIII alles, was nicht direkt zum Streamen gehört (vor allem XChat und Browser) kurzerhand aufs Notebook verlegt, denn obwohl sie nicht direkt zum Streamen gehören, brauche ich sie doch gleichzeitig. Der Grund für die Verlegung war, daß jeder Fensterwechsel, jede Mausbewegung und auch schnelles Tippen im Stream als Störungen zu hören sind, und das nervt auf Dauer doch sehr. Auch ein zwischendurch eingesetzter Duron mit 850 MHz hatte das Problem noch; erst ab dem Athlon mit 1533 MHz ist das Problem Geschichte.

Als erstes startet man audacious, aumix und darksnow und ordnet die Fenster so an, daß man möglichst alles sehen kann (incl. Playliste). Den alsamixer braucht man nur anfangs, um die Soundkarte, falls nötig, vorzukonfigurieren.

Als nächstes aumix richtig einstellen: Dabei nehme ich immer erstmal alle Anzeigen raus, die ich nicht benötige; leider merkt der sich das nicht (auch nicht durch save). Dann drehe ich PCM bzw. Master auf 70 bis 80 und Mic auf 100 % und regle die Lautstärke (das ist die des eigenen Kopfhörers bzw. Lautsprechers) auf einen mir angenehmen Wert. Im alsamixer schalte ich ggf. noch den Mic-Booster ein. Vorsicht, wenn mit Lautsprecherboxen statt Kopfhörer am Stream-PC gearbeitet wird! Den Booster dann nicht zu hoch drehen, sonst gibt es eine Rückkopplung, und das pfeift ganz eklig :-)

Ja, und schließlich im darksnow auf Start Streaming klicken.

Erste Kontrolle: Mit einem Browser auf die Webseite des Servers gehen (http://radio.meinserver.de:8000). Dort sollte die „status page“ des icecast2 zu finden sein. Wenn im grauen Bereich die Angaben zu finden sind, die man vorher im darksnow bei „Server Description“ eingetragen hat, ist die Verbindung zum Server aufgebaut.

Das heißt aber noch nicht, daß aufgeschaltete Hörer etwas hören können. Um etwas auf den Stream abzuspielen, muß im aumix bei PCM (oder Master) der Rec-Knopf gedrückt (rot) sein. Wenn man sprechen möchte, muß der Rec-Knopf vor Mic rot sein. Bei manchen (nicht allen) Soundkarten geht auch beides gleichzeitig, wobei es empfehlenswert ist, beim Abspielen von Musik das Mikro auszuschalten (Rec auf grün) – vor allem, wenn man nicht beim Mitsingen erwischt werden will ;-)

Noch Fragen? Frag mich doch!