Audio-Latenz: Mikrofon- und Lautsprecher-Verzögerung messen
Zusammenfassung (TL;DR)
Eine Akustikgitarre über mein altes USB-Interface aufzunehmen, brachte früher rund 35 ms Round-Trip-Latenz in den Monitoring-Kopfhörern – genug, dass jede rhythmische Phrase sich anfühlte, als würde ich durch nassen Sand waten. Der Wechsel zu einem MOTU M2 mit sauber konfiguriertem ASIO-Treiber brachte das auf den 5-ms-Bereich, und die gleiche Aufnahme wurde sofort von „unspielbar” zu „natürlich”. Das Phänomen ist kein Bug; es ist eine messbare, physische Realität namens Round-Trip-Latenz (RTT). RTT ist die Summe von fünf Stufen: Das Mikrofonsignal füllt einen Eingangspuffer, die Host-Software verarbeitet diesen Puffer, das verarbeitete Signal füllt einen Ausgangspuffer, der DAC wandelt es zurück in Analog, und der finale Schall propagiert durch die Luft zum Ohr (rund 1 ms pro 34 cm). Das Tunable lebt überwiegend in Puffergröße und Treibermodell; ASIO, WASAPI Exclusive, Core Audio und JACK haben jeweils unterschiedliche typische Minima und Plattformgrenzen. Dieser Leitfaden erklärt, wie sich die Komponenten summieren, warum der Samplerate-Puffer-Trade-off weniger intuitiv ist, als er scheint, und wie du echte Ende-zu-Ende-Latenz mit einem Loopback-Kabel, einem Testton und einem Audioeditor misst – statt Marketing-Angaben von „1 ms” zu vertrauen.
Hintergrund und Konzepte
Zwischen einem Mikrofon und einem Lautsprecher macht ein Computer mehr, als den meisten Menschen klar ist. Ein ADC sampelt das Mikrofonsignal mit einer gewählten Samplerate (üblicherweise 48 kHz) und sammelt Samples in einem Eingangspuffer. Sobald der Puffer voll ist – etwa 128 Samples bei 48 kHz, rund 2,67 ms Audio – übergibt der Treiber ihn der Anwendung.
Die Anwendung (eine DAW, ein Kommunikations-Client, ein Browser) verarbeitet den Puffer, wendet Effekte an oder kodiert für die Netzübertragung und schreibt das Ergebnis in einen Ausgangspuffer. Ist der Ausgangspuffer voll, wandelt der DAC ihn in ein Analogsignal um, das den Kopfhörer- oder Line-Ausgang verlässt.
Dann kommt die Welt außerhalb des Rechners. Schall reist bei Raumtemperatur mit rund 343 m/s, was rund 1 ms pro 34 cm bedeutet. Kopfhörer fügen dem praktisch nichts hinzu; ein Monitorlautsprecher quer durch den Raum addiert ein paar Millisekunden zu allem anderen. Ein Monitorpaar bei 1,7 m Sitzabstand trägt rund 5 ms reine Ausbreitung bei – im Datenblatt unsichtbar, aber im Ohr präsent.
Also gilt: Round-Trip-Latenz = Eingangspuffer + Verarbeitung + Ausgangspuffer + DAC + Ausbreitung. Bei fester Samplerate reduzieren kleinere Puffer die Latenz, erhöhen aber die CPU-Last, weil der Audio-Thread häufiger aufwachen muss. Wird die Puffergröße in Samples statt in Zeit angegeben, verkürzt eine höhere Samplerate denselben „N-Samples”-Puffer in Millisekunden, doch höhere Sampleraten erhöhen auch den Durchsatz und belasten Treiber anders, weshalb das kein kostenfreier Weg zur Reduktion der Verzögerung ist.
Das Treibermodell sitzt zwischen Anwendung und Audio-Hardware und hat eigene Latenzcharakteristiken. Unter Windows fügen die klassischen MME- und DirectSound-Pfade aus Kompatibilitätsgründen erheblich Pufferung hinzu; WASAPI Shared ist niedriger, aber vom Mixer vermittelt; WASAPI Exclusive und ASIO umgehen einen Großteil dieses Overheads. ASIO4ALL ist ein generischer ASIO-Wrapper, der hilft, wenn ein herstellerspezifischer ASIO-Treiber fehlt, ist aber kein Ersatz für einen echten Vendor-ASIO – die gemessene RTT auf demselben Focusrite Scarlett 2i2 3rd Gen liegt mit offiziellem Treiber typischerweise deutlich niedriger als mit ASIO4ALL über WASAPI. Auf macOS ist Core Audio als Plattformdefault bereits auf niedrige Latenz getrimmt. Auf Linux erreichen die JACK- und PipeWire-Stacks sehr niedrige Latenz, sobald konfiguriert, brauchen aber Echtzeit-Kernel-Scheduling für Konsistenz.
Vergleich und Daten
| Kriterium | ASIO | WASAPI Exclusive | Core Audio | JACK |
|---|---|---|---|---|
| Plattform | Überwiegend Windows | Nur Windows | Nur macOS | Linux-zentriert, plattformübergreifende Ports existieren |
| Typisch niedrigste Latenz | Sehr niedrig, häufig im unteren Millisekundenbereich | Niedrig bei exklusiver Nutzung | Niedrig und stabil im unteren Millisekundenbereich | Sehr niedrig bei guter Konfiguration, mehr Setup-Komplexität |
| Sharing-Modell | Treiberabhängig (typisch exklusiv) | Shared oder exklusiv; exklusiv hat niedrigere Latenz | Gut getunter Shared-Modus ist der Default | Routing-Matrix-basiert, multi-client |
Exakte Millisekundenwerte hängen stark von Hardware, Treiber und OS-Version ab, statt also dem Spruch „1 ms Latenz” auf einer Produktseite zu glauben, miss dein eigenes System einmal, um eine Baseline zu etablieren. Erschwingliche Interfaces wie das MOTU M2 und das Focusrite Scarlett 2i2 3rd Gen erreichen Round-Trips im einstelligen Millisekundenbereich, wenn sie mit einem echten ASIO- oder Core-Audio-Treiber gepaart sind, aber dieselbe Hardware über einen Windows-Shared-Mode-WASAPI-Pfad oder über ASIO4ALL-Wrapper schneidet typischerweise merklich schlechter ab. Deine echte RTT ist das gemeinsame Ergebnis dreier Variablen – Interface, Treiber, Puffergröße – und eine davon isoliert anzunehmen, ist selten genau.
Praxisszenarien
Szenario 1 – Live-Performance und In-Ear-Monitoring. Eine Sängerin, die ihre eigene Stimme über In-Ear-Monitore hört, empfindet schon wenige Millisekunden Verzögerung als Timing-Problem. Das Ziel hier ist RTT unter 10 ms, was meist kleine Puffergrößen, einen Low-Latency-Treiber (ASIO unter Windows, Core Audio auf macOS) und – wo möglich – das Hardware-Direct-Monitoring des Interfaces erfordert, das den Softwarepfad für das Monitoring-Signal komplett umgeht. Der Monitor-Knob an der Frontseite des MOTU M2 löst das mit einer Drehung, und der „Direct”-Schalter des Scarlett 2i2 3rd Gen macht dasselbe.
Szenario 2 – Podcast-Aufnahme. Sofern nicht mehrere Gastgeber:innen einander live abhören, sind 50 bis 100 ms RTT in der Regel in Ordnung während der Aufnahmesession. Die Postproduktion gleicht die Spuren ohnehin ab, und ein größerer Puffer verbessert die CPU-Reserve, was wiederum das Risiko von Dropouts in einer langen Aufnahme reduziert. Hier auf niedrigste Latenz zu optimieren, schadet häufiger, als es hilft.
Szenario 3 – Videokonferenzen. Browser-basierte WebRTC-Calls operieren typischerweise in einem Bereich von rund 100 bis 200 ms Ende-zu-Ende, weil Netzwerk, Encoding und Jitter-Pufferung zur lokalen Audio-Latenz hinzukommen. Das liegt nahe der Grenze, an der Gesprächswechsel sich natürlich anfühlen; Bluetooth-Earbuds mit älterem Codec können das über diese Schwelle schieben, weshalb Teilnehmer:innen beginnen, sich gegenseitig ins Wort zu fallen.
Szenario 4 – Online-Musikkollaboration. Synchrone Musik mit einer Remote-Partnerin über das Internet zu spielen, ist das unversöhnliche Ende dieses Spektrums. Jenseits von rund 25–30 ms Einwegverzögerung wird es schwer, ein stabiles Tempo zu halten, und typisches Heim-Internet plus Consumer-Audiosoftware landet regelmäßig deutlich darüber. Spezialisierte Low-Latency-Kollaborationsplattformen existieren genau, um jede mögliche Millisekunde zu ersparen, und selbst dann verlangen sie meist kabelgebundenes Ethernet, sorgfältiges Treiber-Tuning und physische Nähe im Internet-Backbone. Zu erkennen, dass ein Consumer-Video-Call-Stack das falsche Werkzeug dafür ist, ist meist der erste Schritt.
Häufige Missverständnisse
„Bluetooth-Audio hat immer hohe Latenz.” Klassisches A2DP-Streaming fügt in der Tat erhebliche Verzögerung hinzu. Doch neuere Codecs wie LE Audio (LC3) und aptX Low Latency drücken das deutlich, was einen Kategoriewechsel im gefühlten Verhalten darstellt. Zwei Kopfhörer, die beide „Bluetooth” sagen, können sich dramatisch unterscheiden, abhängig vom Codec, den sie und die Quelle unterstützen. Fürs Monitoring einer Aufnahmesession bleibt verkabelt trotzdem die sicherere Wahl.
„USB-Audio ist immer besser als Analog.” USB-Audio schlägt Onboard-Analog, wenn das Interface einen guten DAC, saubere Preamps und stabile Treiber hat. Billige USB-DACs können wegen Jitter, Rauschen und Treiberproblemen sogar schlechter sein. „USB” allein impliziert keine Qualität; die Komponentenwahl tut es.
„Samplerate 192 kHz bedeutet niedrigere Latenz.” Kontraintuitiv, aber wichtig: Wird der Puffer in Zeit (ms) angegeben, reduziert eine höhere Samplerate die physische Latenz nicht. Nur wenn der Puffer in Samples fix ist, bedeutet eine höhere Samplerate weniger Millisekunden pro Puffer – zum Preis von mehr Daten pro Sekunde, mehr CPU und mehr Treiberstress. Niedrige Latenz entsteht vorrangig durch kleinere Puffer und ein besseres Treibermodell, nicht durch höhere Samplerate.
„Software-Monitoring und Hardware-Monitoring fühlen sich gleich an.” Tun sie nicht. Software-Monitoring führt das Mikrofonsignal durch den DAW-Pfad – Eingangspuffer, Plug-in-Verarbeitung, Ausgangspuffer – und akkumuliert dabei RTT. Hardware-Monitoring an einem Audio-Interface schickt das Mikrofonsignal direkt an den Kopfhörerausgang innerhalb des Interfaces und umgeht den Computer für den Monitoring-Pfad komplett. Die Performer:in hört sich mit praktisch null Latenz, während der Computer die Spur trotzdem für die spätere Produktion aufzeichnet. Viele Setups verwechseln beides und beschuldigen die Puffergröße für eine Verzögerung, die Hardware-Monitoring in einer Einstellungsänderung beseitigen würde.
Checkliste
- Definiere das RTT-Ziel für deinen Anwendungsfall. Live-Performance: unter 10 ms; Aufnahme: 50–100 ms sind in Ordnung; Videokonferenz: 100–200 ms sind realistisch.
- Wähle das Treibermodell. Unter Windows ASIO oder WASAPI Exclusive; auf macOS Core Audio; auf Linux JACK oder PipeWire. Die Standard-Shared-Mode-Stacks (MME, Default-Shared-WASAPI) haben meist die höchste Latenz.
- Senke die Puffergröße schrittweise bis knapp vor die ersten Dropouts. Das ist der praktische Boden deines Systems.
- Mache eine Loopback-Messung. Verbinde den Output des Interfaces mit seinem Input per Kabel, spiele einen Testton und lies die Verzögerung aus der aufgenommenen Wellenform in einem Audioeditor.
- Passe die Samplerate an den Projektbedarf an. 48 kHz ist typisch für Videoarbeit; 44,1/48 kHz für Musik. Nur mit konkretem Grund darüber gehen.
- Nutze den Monitoring-Pfad klug. Wo möglich, nutze das Direct-Monitoring-Feature des Interfaces für die Ohren der Performer:in, was die Monitoring-RTT praktisch auf null bringt, selbst wenn der Aufnahmepfad einige Millisekunden Latenz hat.
Verwandtes Tool
Das Audio-Latenz-Tool von Patrache Studio schätzt die Round-Trip-Latenz im Browser, was eine grobe Messung ohne Hardwarekauf erleichtert. Fürs weitere „Input-Latency”-Bild im Gaming-Kontext siehe Tastatur-NKRO und Input-Lag fürs Gaming. Wenn du ein Videoanruf-Setup tunst, bei dem Audio-Delay die A/V-Synchronität beeinflusst, kombiniere diesen Leitfaden mit Webcam-Diagnose: Framerate, Auflösung und Licht, um die kameraseitige Latenz zu verstehen, die sich auf die Audio stapelt.
Quellen
- Steinberg-ASIO-Dokumentation — https://www.steinberg.net/en/company/technologies/asio.html
- Microsoft Learn, Low-Latency-Audio unter Windows (WASAPI) — https://learn.microsoft.com/en-us/windows-hardware/drivers/audio/low-latency-audio
- Bluetooth SIG, LE-Audio-Spezifikationen — https://www.bluetooth.com/specifications/specs/le-audio