Ob die Musik aussetzt oder der Lautsprecher knackt – die Ursache vieler Audioprobleme mit Linux sind hohe Latenzzeiten, das System verarbeitet Signale also nicht schnell genug. Dieser Workshop zeigt, wie Sie den Linux-Computer für niedrige Latenz tunen.

Musiker sind anspruchsvolle Linux-Anwender, denn Schwachpunkte im Kernel machen sich sofort als hässliche Störungen bei der Tonwiedergabe bemerkbar. Zusammen mit den Videoliebhabern sind die Linux-Sound-Anwender eine treibende Kraft bei der Weiterentwicklung von Echtzeiteigenschaften des Linux-Kernels. Bislang musste Linux besonders im Bereich der Latenzzeiten einige Kritik einstecken. “Sogar noch schlechter als Windows”, spotteten die Musiker.

In der Tat: Vor allem mit dem alten Kernel 2.4 war das aussetzungsfreie Abspielen längerer Musikstücke oder der ruckelfreie Genuss einer DVD nur mit Kernel-Patches möglich. Der ambitionierte Musiker hatte die Wahl zwischen dem Low-Latency- und dem Preemption-Patch. Nur ein mit beiden Patches ausstaffierter Kernel brachte die Linux-Klangwelt halbwegs in Ordnung (siehe Kasten “Audio mit dem Kernel 2.4”).

Das Preemption-Patch hat Linus Torvalds in Kernel 2.6 aufgenommen. Das bescherte zumindest dem Laien akzeptablen Musikgenuss – Profis jedoch klagten und patchten weiterhin. Erst seit Kernel 2.6.10 schlagen die Musiker versöhnlichere Töne an: Auf der 3. Internationalen Linux-Audio-Konferenz dieses Jahr in Karlsruhe stellte Fernando Pablo Lopez-Lezcano vom Center for Computer Research in Music and Acoustics (CCRMA) fest, dass Version 2.6.10 der erste Linux-Kernel ist, der sich auch ohne Patches einsetzen lässt [1].

Xruns stören

Doch falsch konfiguriert kann es auch mit einem geeigneten Kernel zu den gefürchteten Xruns kommen: Puffer-Über- oder Unterläufe, die entstehen, wenn die Applikation die Audiodaten nicht rechtzeitig von der Audiohardware abholt respektive wenn das Soundprogramm die Daten der Audiohardware nicht rechtzeitig übergibt (siehe Kasten “Echtzeitanforderungen …”). Auch ein ungeschultes Ohr nimmt Over- oder Underruns als Aussetzer oder als Klicks wahr.

Wenn Sie selbst bei geringer Last unter Xruns leiden, sollten Sie vor allem folgende Maßnahmen beherzigen (siehe Abbildung 1): Verwenden Sie am besten einen aktuellen Linux-Kernel. Ist die Option »PREEMPTIBLE_KERNEL« eingeschaltet, verbessert dies das Echtzeitverhalten noch einmal signifikant (siehe Abbildung 2). Achten Sie also darauf, dass diese Option eingeschaltet ist (das ist wohl bei den meisten Distributionskernels der Fall). Sollte Ihre Audiohardware zudem per USB angeschlossen sein, sind die Punkte »Enforce USB bandwith allocation« und »Dynamic USB minor allocation« abzuwählen.

Festplatten mit DMA

Stellen Sie sicher, dass Plattenzugriffe über DMA durchgeführt werden. Das Programm »hdparm« gibt Aufschluss hierüber und schaltet bei Bedarf den DMA-Transfer ein:

# hdparm -d /dev/hdc
/dev/hdc:
 using_dma    =  0 (off)
# hdparm -d 1 /dev/hdc
/dev/hdc:
 setting using_dma to 1 (on)
 using_dma    =  1 (on)

Vergessen Sie nicht auch bei DVD- oder CD-ROM-Laufwerken den DMA-Transfer zu aktivieren.

Eine dritte Maßnahme verringert darüber hinaus potenzielle Ruckler: Die Vergabe einer Echtzeitpriorität an die Rechenprozesse, die die Musik verarbeiten. Die Auswirkung dieser Maßnahme gibt für eine Applikation ohne Echtzeitpriorität die Abbildung 3 wieder; das Ergebnis bei eingeschalteter Echtzeitpriorität zeigt Abbildung 4.

Abbildung 1: Wenn Sie die grün unterlegten Maßnahmen beherzigen, laufen Audio-Applikationen störungsfrei. Die rot markierten Aktionen sollten Sie vermeiden.

Echtzeitpriorität

Die meisten Programme bieten zur Aktivierung der Echtzeitpriorität einen Schalter. Bei »xmms« beispielsweise befindet er sich im Optionen-Menü (siehe Abbildung 5). Unter KDE findet sich für »artsd« ein entsprechender Eintrag im Kontrollcenter unter »Sound System«, siehe Abbildung 6. Auch der für niedrige Latenzen konzipierte Soundserver »jackd« verarbeitet die Option »–realtime -P Realtime-Priorität« (da-zu mehr in dem entsprechenden Artikel dieses Heft-Schwerpunkts).

Auch Applikationen, die keinen eigenen Schalter für das Einstellen der Echtzeitpriorität besitzen, lassen sich mit Realzeitpriorität versehen. Dazu dient das Programm »chrt«, das in dem Paket »sched-utils« zu finden ist. Wenn Ihre Soundkarte per USB angeschlossen wird, sollten Sie beim Laden des Soundmoduls die Option »nrpacks=1« zusätzlich angeben:

modprobe snd-usb-audio nrpacks=1

Diese Option sorgt dafür, dass bei jedem Datentransfer zwischen USB-Gerät und Rechner nur ein Paket ausgetauscht wird. Eine Anleitung zu USB-Sound findet sich unter [2].

Mit diesen Maßnahmen kommt es unter normalen Umständen zu keinen Aussetzern mehr. Normal bedeutet, dass Sie nicht ständig zwischen der Grafik- und der Textkonsole hin- und herschalten und dass keine außergewöhnliche Lastsituation besteht.

Abbildung 2: Für kurze Latenzzeiten sollten Sie bei der Kernelkonfiguration einstellen, dass auch Kernfunktionen unterbrechbar (preemptible) sind.

In Arbeit: Realtime Preemption

Wer unter Last die Echtzeitanforderungen von Audio in jedem Fall erfüllen will, kann demnächst eventuell noch tiefer in die Trickkiste greifen. So arbeitet Ingo Molnar seit einiger Zeit an der so genannten Realtime Preemption, die bis vor kurzem noch Voluntary Preemption hieß. Der Clou dieser Arbeiten ist, die bisher gleichberechtigten Interrupt-Service-Routinen (ISR) zu priorisieren (siehe Abbildung 7). Da sie zugleich normalen Threads entsprechen, besteht damit sogar die Möglichkeit, einen Thread vor einer Interrupt-Service-Routine abarbeiten zu lassen!

Abbildung 3: Ohne Echtzeitpriorität wird die Deadline (rot) von 2,9 Millisekunden mehrfach verletzt. Hier das Ergebnis mit Linux-Kernel 2.6.12 und eingeschalteter Kerneloption »PREEMPTIBLE_KERNEL«, aber ohne Realzeitpriorität der Testapplikation. Mehr Details zum durchgeführten Test beschreibt der Artikel.

Abbildung 4: Starten Sie die Audio-Applikation mit Echtzeitpriorität, wird die Echtzeit-Deadline nur selten verletzt.

Damit können Sie Audiotasks samt zugehöriger Interrupt-Service-Routine mit höchster Priorität versehen und sämtliche andere Aktivitäten der Musikverarbeitung unterordnen. Allerdings ist das Patch noch mit großer Vorsicht zu genießen. Die Arbeiten laufen noch auf Hochtouren – kein Wunder, dass der Kernel im Test regelmäßig zum Einfrieren respektive zum Absturz des Systems führte. Ein weiterer Wermutstropfen: Das Preemption-Patch benötigt einen guten Teil der vorhandenen Rechenleistung für sich. Auch auf dieser Baustelle muss noch einiges geschehen.

Der Effekt, den die vorgeschlagenen Maßnahmen auf die kritische Latenzzeit haben, lässt sich mit Zahlen belegen. Zum Test der Latenzzeiten diente das Programm »latencytest« von Benno Senoner [3]. Testobjekte waren ein Standardkernel 2.6.12 ohne die Option »PREEMPTIBLE-KERNEL«, einer mit dieser Option und ein weiterer Standardkernel 2.6.12, aber gepatcht mit »realtime preemption«. Dabei startete das Programm »latencytest« selbst einmal mit und einmal ohne Echtzeitpriorität. Zur Messung der Latenzzeit spielt es bei einer Samplingrate von 44100 Hz einen Ton ab (PCM I/O).

Nach spätestens 2,9 Millisekunden muss die Audiohardware einen neuen Buffer erhalten – das ist die Deadline. Bevor das Testprogramm allerdings den nächsten Buffer übergibt, beansprucht es 80 Prozent der Rechenzeit (als Simulation einer echten Audio-Applikation). Um Worst-Case-Zeiten zu ermitteln, setzt Benno Senoner das System unter mehrere Lastzustände, etwa durch Zugriffe auf Dateien im Proc-Verzeichnis oder durch massive Plattenzugriffe.

Die Resultate zeigen Tabelle 1 sowie die Abbildungen 3 und 4, allerdings exemplarisch nur für eine spezifische Lastsituation, nämlich das Kopieren von Daten auf der Festplatte (Disk Copy). Das Testsystem war mit einem Pentium-M-Prozessor (1,4 GHz) und 512 MByte RAM ausgestattet.

Realtime-Priorität bringt’s

Tabelle 1 zeigt, dass ein Standardkernel mit der Option »PREEMPTIBLE_KERNEL« die geringsten Latenzzeiten aufweist und zudem als einziger seine Deadline einhält (Overruns = 0). Die Option »PREEMPTIBLE_KERNEL« hat dabei einen signifikanten Einfluss auf das Ergebnis.

Zunächst überrascht das schlechte Abschneiden der Realtime Preemption. Das liegt zum einen daran, dass sich das Patch noch in der Entwicklungsphase befindet, zum anderen aber auch daran, dass der Kernel nicht optimal für das Patch konfiguriert war. Darüber hinaus ist zu erwarten, dass unter sehr hoher Last die Latenzzeit auch bei einem Standardkernel höher ausfällt als hier angegeben. Denn die Unfähigkeit, den wirklichen Worst-Case sicher zu produzieren, haben alle Latenzmessungen gemeinsam. Trotz solcher Messprobleme lässt sich aber abschließend feststellen, dass sich die aktuellen Linux-Kernel auch für den Multimedia-Einsatz eignen.

Abbildung 5: XMMS ermöglicht die Vergabe einer Echtzeitpriorität über das Optionen-Menü. Damit diese Einstellung wirksam wird, muss das Audioprogramm mit Superuser-Privilegien laufen.

Abbildung 6: KDE verwendet als Soundserver »artsd«, dessen Echtzeitpriorität sich im Kontrollcenter einstellen lässt (rot markiert).

Abbildung 7: Ingo Molnars Realtime Preemption bildet alle Interrupt-Service-Routinen und Tasklets auf Kernel-Threads ab. Mit Hilfe des Kommandos »ps« lassen sich die PIDs dieser Prozesse feststellen.

Priorisieren ohne Root-Rechte

Den Entwicklern ging es nicht nur um zu hohe Latenzzeiten, sie kümmerten sich auch um die Vergabe von Echtzeitprioritäten durch normale Benutzer: Bei entsprechender Konfiguration erlaubt es Kernel 2.6.12, über den RT-Limits-Mechanismus Applikationen auch ohne Superuser-Privilegien zu priorisieren. Da es wohl noch dauern wird, bis die Distributoren dieses Feature unterstützen, müssen Sie zurzeit noch selbst Hand anlegen. Eine Anleitung zu RT-Limits findet sich im Internet unter [7]. (ofr)