Konfiguration
Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:
Dieser Artikel ist mit keiner aktuell unterstützten Ubuntu-Version getestet! Bitte teste diesen Artikel für eine Ubuntu-Version, welche aktuell unterstützt wird. Dazu sind die Hinweise zum Testen von Artikeln zu beachten.
Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:
⚓︎ Ein Terminal öffnen, optional
Dieser Artikel befasst sich mit Anpassungen für eine spezialisierte Audio-Workstation, die Klangwiedergabe mit niedrigen Latenzen ermöglichen. Das ist für Normalanwender irrelevant, kann aber für die Musikproduktion von entscheidender Bedeutung sein. Die einfachste und in den meisten Fällen ausreichende Vorgehensweise ist die Installation und Nutzung von Ubuntu Studio. Die wichtigsten der in diesem Artikel erwähnten Konfigurationsschritte werden dabei automatisch vorgenommen.
Latenz und Puffer¶
Ein Prozessor wechselt ständig zwischen zahlreichen Aufgaben hin und her: Festplatten und RAM müssen beschrieben und gelesen werden, die Grafikkarte braucht Informationen, zwischendurch kommen Daten von Tastatur oder Maus und so weiter. Die verschiedene Aufgaben stehen auf einer Liste und warten, bis sie dran sind. Auf dieser Liste steht auch der Audio-Eingang.
Wenn aber Audiodaten von den Analog-Digital-Wandlern ankommen, geschieht das mindestens 44.100 Mal pro Sekunde. Normale Kernels sind darauf eingestellt, in jeder Sekunde ein paar Hundert Ereignisse abzufragen, aber nicht mehrere zehntausend. Das Interface sammelt also eine Weile (es "puffert") und übergibt dann gleich mehrere Samples auf einmal zur Verarbeitung weiter. Genau andersrum funktioniert die Audio-Ausgabe: Das Interface holt sich mehrere Samples auf einmal ab und gibt sie dann eins nach dem anderen aus.
Wichtig ist nun, dass der Puffer nie leer läuft: Es muss immer rechtzeitig der nächste Block Samples übergeben werden, sonst gibt es hässliche Knackgeräusche oder die Aufnahme ist ruiniert. Und deswegen muss der Linux-Kernel für die Audiobearbeitung darauf optimiert werden, zuverlässig in sehr kurzen Abständen Audiodaten abzuholen und auszuliefern. Für die meisten anderen Anwendungen ist das nicht in dem Maße nötig.
Kernel¶
Es gibt spezielle Kernel, die auf niedrige Latenzen optimiert sind. Das können entweder Echtzeitkernel sein oder als gemäßigte Variante sog. Lowlatency-Kernel, wie sie z.B. unter Ubuntu Studio eingesetzt werden. Beide Kerneltypen können zu erhöhtem Stromverbrauch und verminderter Batterielaufzeit führen, sind aber für sehr niedrige Latenzen unabdingbar. In der Praxis genügen dabei allerdings Lowlatency-Kernel den meisten Anforderungen, so dass man nur sehr selten auf Echtzeitkernel zurückgreifen muss.
Wer für Audiozwecke zwingend kleinstmögliche Latenzen benötigt, sollte ggf. sicherstellen, dass er speziell für den Audioeinsatz optimierte Kernel verwendet. Diese können sich - wie hier 🇫🇷 erläutert - im Detail von herkömmlichen Lowlatency- und Echtzeitkerneln unterscheiden.
Echtzeitrechte für die Benutzergruppe Audio¶
Der Soundserver Jackd benötigt zum zuverlässigen Betrieb besondere Rechte. Diese Rechte kann man der Gruppe audio zuweisen, indem man mit einem Editor mit Root-Rechten [2] die Datei /etc/security/limits.conf bearbeitet. Vor Schluss sind zwei Zeilen einzufügen, das sieht dann so aus:
@audio - rtprio 99 @audio - memlock unlimited
Die Rechte stehen erst nach einer Neuanmeldung am System zur Verfügung.
Der Gruppe Audio tritt man dann mit dem Befehl [1]
sudo usermod -a -G audio BENUTZERNAME
bei.
Optionale Anpassungen bei Problemen¶
Die folgenden zusätzlichen Anpassungen sind in vielen Fällen überflüssig und sollten nur bei konkreten Problemen versucht werden.
Xruns bei Verwendung von JaMin¶
JaMin ist ein sehr anspruchsvolles Werkzeug. Unter Umständen funktioniert es selbst bei ansonsten aufwändig angepasstem System nicht einwandfrei. Es kann aber möglich sein, einen zuverlässigen Betrieb durch einfaches Abschalten des Duplexmodus in Jack zu erreichen - beim Mastern wird ja ohnehin keine Aufnahmefunktion benötigt.
Dateisysteme¶
Das standardmäßig verwendete ext4-Dateisystem kann beim Schreiben erhöhte Latenzen haben. Besser sind in dieser Hinsicht ext2 (dem allerdings die Journalfunktion fehlt), ReiserFS und das besonders bei großen Dateien sehr leistungsfähige XFS. Bei letzterem drohen allerdings nach einem Stromausfall größere Datenverluste als bei anderen Dateisystemen, da es besonders exzessiv von Puffermechanismen Gebrauch macht.
Ob die Leistungsunterschiede zwischen den Dateisystemen für den Lowlatency-Betrieb tatsächlich praktische Relevanz haben, scheint strittig.
noatime-Option für die Dateisysteme ext3 und ext4¶
Bei der Audioaufnahme ergeben sich immer wieder Performance-Probleme, wenn das Betriebssystem von der selben Festplatte läuft, auf die auch die Audiodateien geschrieben werden sollen (unabhängig von der Partition). Aufgrund des gleichzeitigen Zugriffs von Betriebssystem und Audiosoftware auf das Dateisystem können sich, vor allem bei Programmen, die nur geringe Puffer einsetzen, Probleme ergeben. Speziell Ardour ist hierfür anfällig und quittiert dies unter Umständen mit der Fehlermeldung:
"the disk system on your computer could not keep up with Ardour".
Eine Möglichkeit zu verhindern, dass sich Betriebssystem und Audioprogramm während Aufnahmen in die Quere kommen, ist die entsprechenden Partitionen mit der -noatime-Option einzuhängen. Wie dies umzusetzen ist und was -noatime genau bedeutet, kann im Wiki-Artikel Tuning (Abschnitt „noatime“) nachgelesen werden.
Priorisierung und Latenzanpassungen für Hardwarekomponenten¶
Anpassung der PCI-Latenzen (für Nvidia-Grafikkarten mit proprietärem Treiber)¶
Der Grafiktreiber von Nvidia beansprucht das System unter Umständen in einer Weise, die den Lowlatencybetrieb für andere PCI-Geräte beeinträchtigt (auch AGP gehört zum PCI-System). Dies äußert sich in Knistern, sobald ein 3D-Programm gestartet wird. Am sichersten lässt sich das Problem vermeiden, indem man konsequent auf 3D-Programme oder gar 3D-Desktops verzichtet oder gleich ganz auf den ohnehin optionalen 3D-Treiber verzichtet.
Scheint dies unzumutbar, lässt sich unter Umständen etwas durch Anpassung der PCI-Latenzeinstellungen erreichen.
Beispiel für PCI-Latenzanpassung¶
Achtung!
Änderungen am PCI-Subsystem können zu irreparablen Hardwareschäden führen und sollten absoluten Experten vorbehalten sein.
Mit dem folgenden Befehl [1] bekommt man eine ausführliche Auflistung des PCI-Bus:
lspci -v
Der Abschnitt für die Grafikkarte sieht beispielsweise so aus:
01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev a1) (prog-if 00 [VGA])
Subsystem: CardExpert Technology Unknown device 0001
Flags: bus master, 66MHz, medium devsel, latency 176, IRQ 16
Memory at f5000000 (32-bit, non-prefetchable) [size=16M]
Memory at e8000000 (32-bit, prefetchable) [size=128M]
[virtual] Expansion ROM at f6e00000 [disabled] [size=64K]
Capabilities: <access denied>Wichtig ist der Eintrag latency (hier 176) sowie die Adresse der Karte (hier 01:00.0).
Dieser Eintrag latency hat folgende Bedeutung:
je kleiner der Wert, umso schneller muss das Gerät den Bus freigeben. Umso kleiner sind dadurch aber auch die Datenpakete, die in einem "Burst" gesendet werden können.
je größer der Wert (maximal 255), umso länger kann das Gerät den Bus belegen, und umso größer sind die Datenpakete, die gesendet werden können.
Es handelt sich also immer um einen Kompromiss. Der Standardwert für die meisten Geräte ist 176, hexadezimal b0.
Möglicherweise kann durch eine Verringerung dieses Werts für die Grafikkarte erreicht werden, dass der Bus für die Soundkarte ausreichend verfügbar ist. Um nun den Wert für das PCI-Gerät 01:00.0 auf 128 zu setzen (hexadezimal 80), dient der folgende Befehl:
sudo setpci -v -s 01:00.0 latency_timer=80
Möglicherweise muss mit den Werten experimentiert werden, um eine gute Balance zu finden. Auch eine Anpassung der Werte für die Grafikkarte kann sinnvoll sein, sie erfolgt entsprechend. Sind gute Werte gefunden, kann man die Schritte in einem Startskript [3] automatisieren.
Priorisierung von Hardwareinterrupts¶
Hinweis:
Dieser Abschnitt erfordert mehr Erfahrung im Umgang mit Linux und ist nur für fortgeschrittene Benutzer gedacht.
Bei Verwendung eines Echtzeitkernels ist es möglich, die Behandlung bestimmter Interrupts zu priorisieren. Dies ermöglicht eine besondere Bevorzugung der Soundkarte. Zunächst muss festgestellt werden, welcher Interrupt für die Soundkarte verwendet wird. Alle Interrupts sind in der Datei /proc/interrupts aufgelistet. Bei Verwendung eines Echtzeitkernels werden Interrupts von Threads im Userspace behandelt. Diese tragen zum Beispiel den Namen IRQ-xx, wobei xx durch eine Ganzzahl zu ersetzen ist.
Mit Hilfe des Befehls chrt kann nun einem Interrupt eine höhere Echtzeitpriorität zugewiesen werden. Beispiel:
sudo chrt -p 80 `pidof "IRQ-11"`
Dieser Befehl sorgt dafür, dass der für die Behandlung des Interrupts 11 zuständige Thread die recht hohe Echtzeitpriorität 80 bekommt.
Weitere Hinweise¶
Mehrprozessorsysteme können zu deutlicher Leistungssteigerung führen.
Bestimmte ältere VIA- und NVidia-Chipsätze haben Probleme mit gleichzeitigen PCI- und IDE-Transfers und sind insofern schlecht geeignet.
DDRAM und Nachfolger sind als Arbeitsspeicher zu bevorzugen. Weniger als 256 MiB sind nur bei reduzierten Anforderungen und mit einer besonders ressourcensparenden Installation möglich, mehr als 512 MiB sind immer gut.
Für zuverlässigen Betrieb mit niedrigsten Latenzen sind hochwertige Soundkarten nötig, beispielsweise von RME 🇩🇪 oder M-Audio 🇩🇪. Das bedeutet aber nicht, dass man mit anderen Karten kein Glück haben kann - selbst mit USB-Karten wurden schon erstaunlich niedrige Latenzen erreicht. Es sind prinzipiell alle Karten verwendbar, die von ALSA, Open_Sound_System oder Freebob 🇬🇧 unterstützt werden.
Wichtiger als die "Leistung" der Hardware ist ihre Qualität. So kann ein altes Notebook mit Pentium 3-600, 192 MiB RAM und USB-Soundkarte innerhalb gewisser Grenzen (Spuranzahl) absolut zuverlässig laufen, während ein schlechter VIA-Chipsatz und eine Nvidia-Grafikkarte die Vorteile eines an sich schnellen Systems und einer PCI-Soundkarte zunichte machen können und im schlimmsten Fall überhaupt keinen zuverlässigen Betrieb erlauben.
Links¶
Tonstudio - Hauptartikel