Wie ein Mikrofon-Test im Browser funktioniert (Web Audio)

Ein Mikrofon-Test im Browser wirkt von außen simpel: Sie klicken auf einen Button, erlauben den Zugriff und sehen einen Balken, der mit Ihrer Stimme tanzt. Dahinter steht eine klar definierte Kette aus standardisierten Web-Schnittstellen. Dieser Artikel beschreibt, wie der Browser den Audio-Stream beschafft, wie er den Pegel berechnet, welche Rolle die Sample-Rate spielt und warum der Zugriff zwingend an HTTPS gebunden ist. Ziel ist ein technisch sauberes Verständnis, ohne dass Sie selbst Code schreiben müssen.

getUserMedia holt den Audio-Stream

Am Anfang steht ein Aufruf von navigator.mediaDevices.getUserMedia(). Diese Methode bekommt ein sogenanntes Constraints-Objekt übergeben, in dem die Seite beschreibt, was sie möchte, etwa { audio: true } oder genauer, welches Eingabegerät und welche Vorverarbeitung erwünscht ist. Der Browser prüft daraufhin die Berechtigung. Liegt keine Erlaubnis vor, erscheint der bekannte Berechtigungsdialog.

Erteilen Sie die Erlaubnis, gibt die Methode ein Promise zurück, das mit einem MediaStream aufgelöst wird. Dieser Stream enthält eine oder mehrere Spuren, im Audiofall genau eine MediaStreamTrack mit dem Live-Signal des Mikrofons. Wichtig: Es handelt sich um einen Live-Datenstrom, nicht um eine Datei. Solange niemand diesen Strom in einen Recorder leitet, existiert kein gespeichertes Audio.

Der Web-Audio-Graph verarbeitet das Signal

Um den Stream auszuwerten, wird ein AudioContext erstellt, die zentrale Laufzeitumgebung der Web Audio API. Aus dem MediaStream entsteht über createMediaStreamSource() eine Audio-Quelle innerhalb dieses Kontexts. Web Audio arbeitet als Graph: Quellen, Verarbeitungsknoten und Ziele werden zu einer Kette verbunden, durch die das Signal fließt.

Für einen Test verbindet man die Mikrofon-Quelle mit einem AnalyserNode. Dieser Knoten ist passiv, er verändert das Signal nicht, sondern liest es mit. Entscheidend ist, dass die Quelle für einen reinen Test nicht mit dem Lautsprecher-Ziel verbunden wird. So vermeidet man Rückkopplung, also das schrille Pfeifen, das entstünde, wenn das Mikrofonsignal direkt wieder über die Boxen ausgegeben würde.

Der AnalyserNode hört zu, ohne einzugreifen. Er ist das Messgerät im Signalweg, nicht der Verstärker.

Wie der Pegel und die Wellenform berechnet werden

Der AnalyserNode stellt zwei Datenarten bereit. Über getByteTimeDomainData() oder getFloatTimeDomainData() liefert er Zeitbereichsdaten, also die Amplitude des Signals über die Zeit. Genau daraus zeichnet ein Test die Wellenform und berechnet die aktuelle Lautstärke. Üblich ist der Effektivwert, der RMS-Wert, der aus den Einzelwerten eines kurzen Fensters gebildet wird und ein wahrnehmungsnäheres Maß für Lautheit ist als ein einzelner Spitzenwert.

Über getByteFrequencyData() liefert derselbe Knoten Frequenzdaten, die per schneller Fourier-Transformation berechnet werden. Damit lässt sich ein Spektrum darstellen, das zeigt, welche Frequenzanteile gerade dominieren. Die Auflösung dieser Analyse steuert die fftSize, eine Zweierpotenz wie 2048, die das Verhältnis zwischen zeitlicher und spektraler Genauigkeit bestimmt.

Die Aktualisierung läuft typischerweise über requestAnimationFrame, das die Auswerteschleife mit der Bildwiederholrate des Bildschirms synchronisiert. Bei 60 Bildern pro Sekunde aktualisiert sich der Pegelbalken also etwa alle 16 Millisekunden, was flüssig und verzögerungsarm wirkt.

Warum die Sample-Rate wichtig ist

Die Sample-Rate des AudioContext gibt an, wie viele Amplitudenwerte pro Sekunde verarbeitet werden. Nach dem Abtasttheorem lassen sich Frequenzen nur bis zur Hälfte der Sample-Rate korrekt erfassen. Bei 48.000 Werten pro Sekunde reicht das bis 24.000 Hertz und deckt damit den gesamten hörbaren Bereich ab. Für reine Sprachverständlichkeit genügen geringere Raten, doch die Browser-Voreinstellung liegt meist bei 44.100 oder 48.000.

Die folgende Tabelle ordnet gängige Werte ein und zeigt, wofür sie typisch sind.

Sample-Rate	Maximale Frequenz	Typischer Einsatz
8.000 / s	4.000 Hz	Telefonie, schmalbandige Sprache
16.000 / s	8.000 Hz	Sprachverarbeitung, Spracherkennung
44.100 / s	22.050 Hz	CD-Audio, Musik
48.000 / s	24.000 Hz	Standard in Browsern und Video

Warum HTTPS zwingend nötig ist

Der Mikrofonzugriff zählt zu den mächtigen Funktionen des Browsers, die nur in einem sicheren Kontext freigegeben werden. Ein sicherer Kontext bedeutet in der Praxis eine über HTTPS ausgelieferte Seite oder localhost während der lokalen Entwicklung. Auf einer unverschlüsselten HTTP-Seite verweigert der Browser getUserMedia und gibt den Stream nicht frei.

Der Grund ist Schutz vor Manipulation und Abhören. Ohne Transportverschlüsselung könnte ein Angreifer im Netzwerk die Seite verändern und unbemerkt Mikrofonzugriff anfordern oder das Signal abgreifen. Die Bindung an HTTPS stellt sicher, dass die Seite, der Sie die Erlaubnis erteilen, auch wirklich die ist, die Sie sehen, und dass der Datenweg verschlüsselt ist.

Alles bleibt im Browser

Der entscheidende Punkt für einen reinen Test: Die gesamte Verarbeitung findet im Browser auf Ihrem Gerät statt. Der MediaStream fließt in den lokalen Web-Audio-Graphen, der AnalyserNode berechnet Pegel und Spektrum, und das Ergebnis wird auf dem Bildschirm gezeichnet. An keiner Stelle dieser Kette ist ein Server beteiligt. Es gibt keinen Upload, keine serverseitige Analyse und keine gespeicherte Audiodatei.

Erst wenn ein Werkzeug zusätzlich eine Aufnahme- und Wiedergabefunktion anbietet, kommt typischerweise ein MediaRecorder ins Spiel, der einen Ausschnitt als lokales Audio-Objekt im Speicher hält, damit Sie ihn anhören können. Auch das geschieht standardmäßig lokal. Ob ein konkretes Werkzeug etwas überträgt, lässt sich technisch an den Netzwerkaufrufen ablesen, nicht an der Web-Audio-Kette selbst.

Was diese Technik in der Summe leistet

Ein Browser-Mikrofontest verbindet drei standardisierte Bausteine zu einer schlanken Mess-Pipeline: getUserMedia beschafft nach expliziter Erlaubnis den Live-Stream, der Web-Audio-Graph führt ihn in einen AnalyserNode, und dieser liefert die Zeit- und Frequenzdaten für Pegel und Wellenform in Echtzeit. Die Sample-Rate bestimmt den erfassbaren Frequenzumfang, die FFT-Größe die spektrale Auflösung, und die Bindung an HTTPS sichert den Zugriff ab. Weil die Analyse vollständig lokal abläuft, ist ein reiner Test schnell, verzögerungsarm und kommt ohne Datenübertragung aus. Wer diese Kette versteht, kann auch beurteilen, was bei einem fehlschlagenden Test technisch schiefläuft, etwa eine fehlende Erlaubnis, ein gesperrtes Gerät oder ein unsicherer Kontext.