Audio-Dropouts beheben

Foren sind voll von Homerecordern, die dasselbe Problem haben wie ich: Dropouts im Echtzeit-Audio-Stream. Und überall kommt meist früher als später der Tipp, die Kernel-Timer-Latenzen zu überprüfen, meist mit dem kostenlosen Tool Resplendence LatencyMon. Dieses zeigt einem präzise und übersichtlich die Probleme in der CPU-Nutzung an. Doch zur eigentlichen Frage schweigt es genauso wie die Foren: Was muss ich tun, um diese Probleme zu beheben? Ich habe mittlerweile eine Antwort!

Die Ausgangskonfiguration

Und zwar beziehe ich mich auf mein nicht mehr ganz neues Business-Notebook Dell Latitude E5430 (non-vPro, Mid 2012) mit Intels 7-Series-Chipsatz, einem Core-i5-3210M-Prozessor und dem einfachen USB-Audio-Interface Alesis iO2 EXPRESS. Betriebssystem ist Windows 7 64-bit, als DAW verwende ich meist Cubase.

Ich habe schon viele andere Computer und Konfigurationen ohne Probleme fürs Homerecording verwendet, doch hegte ich schon länger den Wunsch, meine Aufnahmen mit demselben mobilen Gerät machen zu können, mit dem ich auch meine sonstige Arbeit erledige.

Das Problem

Sofort begannen die Schwierigkeiten: In unregelmäßigen Abständen, zwischen etwa 10 bis maximal 120 Sekunden, wurde der Aufnahme- oder Monitor-Stream für eine halbe Sekunde unterbrochen – faktisch das Ende jedes ernsthaften Aufnahmeversuchs.

LatencyMon meldete vor allem 4 Treiber, die die CPU übermäßig lange belegen und dadurch diese Dropouts verursachen: ACPI.sys, iaStorV.sys, iusb3xhc.sys und USBPORT.SYS.

Wenn man dieses Problem in einem Computertechnik- oder Homerecording-Forum meldet, bekommt man in aller Regel keine konstruktiven Tipps, sondern destruktive Rückfragen zu Sinn und Unsinn einer solchen Frage, zur Berechtigung von alternden Business-Notebooks im Homerecording und der musikalischen Befähigung ohnehin. Solche Off-Topic-Tendenzen sind oft ein Hinweis darauf, dass man sich an diesem Ort keine allzu große Hilfe erwarten sollte.

Die üblichen Verdächtigen

1. Der Schuldige ist pöbelgemäß erstmal ASIO4ALL. Und dann natürlich die Firma Alesis, die sich die Frechheit erlaubt, Audio-Interfaces wie den iO2 ohne proprietären Treiber für Windows anzubieten. Doch ganz klar: Daran liegt es nicht! Ich testete mit meinem anderen USB-Audio-Interface, dem Tascam US-144, gegen. Dieser kommt mit eigenem Windows-7-Treiber, hat aber genau dieselben Probleme.
2. Am nächsten liegt dann das veraltete BIOS und veraltete Chipset-Treiber. Tatsächlich war mein BIOS mittlerweile 11 Versionen weiter und einige Treiber nicht mehr aktuell. Ich habe also mit durchaus einiger Hoffnung und dank Dells hervorragendem Support-Angebot alles aktualisiert – doch das Problem blieb exakt dasselbe.
3. Weiter ging es mit den Energie-Spar-Funktionen des BIOS und des Betriebssystems. In diesem Bereich vermutete auch LatencyMon das Problem. Ich schaltete also alles auf Höchstleistung, USB-Geräte dürfen nicht zum Stromsparen abgeschaltet werden und Intel SpeedStep wird deaktiviert. Aber auch diese Maßnahmen hatten überhaupt keine Auswirkungen auf die Dropouts.
4. Daraufhin habe ich sämtliche nicht benötigten Geräte von meinem System abgehängt bzw. deaktiviert: Docking-Station, Webcam, Scanner, Drucker, Laufwerke, Dongles, USB-Hubs, Eingabegeräte, Soundkarten, Netzwerk-Adapter, serielle und parallele Schnittstellen … ohne Erfolg. Dieselben 4 eingangs genannten Treiber belagerten unvermindert die CPU. Sollte ich etwa meine Systemfestplatte, die USB-Schnittstelle und den Prozessor deaktivieren? Wohl kaum.

An dieser Stelle trotz allem Frust ein großes Lob an Alesis, die mit dem iO2 ein Audio-Interface anbieten, das class-compliant ist, keinen eigenen Treiber braucht und deshalb auch mit Ubuntu Studio einwandfrei funktioniert!

Die richtigen Lösungen

Mit meinen Recherchen und meinem Latein war ich am Ende. Nicht aber mit meinem Willen, das Ausgangsproblem zu lösen und mit diesem alten Laptop doch noch meine Heimstudio-Anforderungen zu erfüllen. Durch mehr oder weniger zufälliges Herumprobieren kam ich dann nach über 5 Stunden auch tatsächlich zum Ziel:

1. Die Intel-RAID-Treiber (iaStorV.sys) konnte ich ja weder entfernen, noch im BIOS von RAID zu AHCI wechseln, ohne Windows neu aufsetzen zu müssen. Auch die aktuellsten Intel-Matrix-Storage-Treiber vom Dell-Support brachten keine zurückhaltendere CPU-Nutzung. Wohl aber der Intel-Rapid-Storage-Treiber! Ich habe ihn direkt von Intel bezogen und gegen einige Widerstände seitens Windows und Gruppenrichtlinien installiert, und er stört die CPU überhaupt nicht mehr. Verstehe einer, warum Dell diesen nicht anbietet und Windows ihn als inkompatibel markiert.
2. Der ACPI-Treiber ist ebenfalls eine Komponente, die man nicht einfach deaktivieren oder deinstallieren kann. Durch systematisches Durchprobieren verschiedener Prozessor-Funktionen konnte ich jedoch seine enorme Aggressivität bändigen. Und zwar liegt die Lösung nicht im Abschalten von Intel SpeedStep, Turbo-Boost oder den C-States, sondern im Abschalten des zweiten Prozessor-Kerns sowie des Hyper-Threadings. Bleibt eins der beiden aktiv, sorgt der ACPI-Treiber konstant für Dropouts. (Es ist übrigens keine wirksame Alternative, stattdessen in Windows bestimmte Prozesse auf nur einen Prozessorkern festzulegen.)
3. Bleibt der USB-Treiber als letzter Störfaktor. Sowohl iusb3xhc.sys als auch USBPORT.SYS glänzten mit großen Kernel-Timer-Latenzen, egal, ob irgendein USB-Gerät angeschlossen war oder nicht. Die Lösung dieses Problems war so einfach wie unglaublich: Im Geräte-Manager von Windows habe ich zufällig den eingebauten Fingerabdrucksensor deaktiviert – und es kehrte Ruhe ein. Hängt dieser Sensor meines Notebooks etwa intern an einem USB-Port? Und wenn Ja: Warum macht er dort solchen Terror? Verstehe das, wer wolle …

Meine Dropouts sind jedenfalls verschwunden. Keine dieser Lösungen hatte ich direkt angestrebt, keine davon war ein Foren-Tipp, keine davon wirkt fundiert oder überzeugend. Doch sind sie es vielleicht dennoch, denn nichts anderes hat funktioniert, und es lässt sich so recht gut arbeiten, auch mit nur einem Prozessorkern. Offenbar hatte ich den anderen gar nie bemerkt.

Immerhin konnte diese Lösung in 5 Stunden auch die 500 Euro sparen, die ein zweites, ähnlich leistungsfähiges System gekostet hätte. Und sie erlaubt es mir, alle meine Anforderungen mit einem einzigen mobilen Gerät abzudecken. Ach ja, und ich habe viel gelernt …

Nachtrag

Manch einer mag sagen, dass auch der WLAN-Adapter für Dropouts sorgen kann. Das ist richtig und auch bei meinem System so, wenn ich WLAN einschalte. Doch ich schalte es einfach nicht ein, dann hat es auch keine negativen Auswirkungen. LatencyMon merkt übrigens, wenn die Schwierigkeiten aus dieser Richtung kommen und weist entsprechend darauf hin – und in der Liste der störenden Treiber taucht dann in der Regel auch die ndis.sys auf.

Dass LatencyMon ferner Page Faults in kritischem Rot anzeigt, heißt nicht, dass man diese beheben könnte oder gar sollte. Solche Seitenfehler gibt es bei einem Betriebssystemen wie Windows 7 einfach aufgrund der Speicherverwaltung, und sie sind auch im Zusammenhang mit Audiostreams kein Problem.