[[Vorlage(Getestet, bionic)]] {{{#!vorlage Wissen [:Terminal: Ein Terminal öffnen] (optional) [:Editor: Einen Editor öffnen] }}} [[Inhaltsverzeichnis(2)]] [[Bild(Wiki/Icons/sound.png, 48, align=left)]] 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 [:Kernel#Echtzeitkernel: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 [https://librazik.tuxfamily.org/doc2/manuel/noyau hier] {fr} 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] {{{#!vorlage Befehl 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 == [:Tonstudio#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 [:Dateisystem: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#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 ==== {{{#!vorlage Warnung Ä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: {{{#!vorlage Befehl 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: }}} 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: {{{#!vorlage 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 === {{{#!vorlage Hinweis Dieser Abschnitt erfordert mehr Erfahrung im Umgang mit Linux und ist nur für fortgeschrittene Benutzer gedacht. }}} Bei Verwendung eines [:Kernel#Echtzeitkernel: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 [:schedutils:chrt] kann nun einem Interrupt eine höhere Echtzeitpriorität zugewiesen werden. Beispiel: {{{#!vorlage Befehl 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 [http://rme-audio.de/haupt_d.htm RME] {de} oder [http://m-audio.de/ M-Audio] {de}. 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:], [wikipedia:Open_Sound_System:] oder [sourceforge:freebob:Freebob] {en} 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 = * [ubuntu_doc:community/UbuntuStudioPreparation:Weitere Tipps in der Ubuntu-Dokumentation] * [:Tonstudio:] - Hauptartikel # tag: Multimedia, Tonstudio