Mikrofon funktioniert unter Linux nicht: So testen und beheben Sie das Problem
Microphone-Test.org ·

Unter Linux ist ein nicht funktionierendes Mikrofon weitaus häufiger stummgeschaltet als defekt. Der ALSA-Aufnahmekanal ist in vielen Distributionen standardmäßig deaktiviert, sodass die Kapsel zwar funktioniert, der Treiber jedoch keine Daten weiterleitet. Eine falsche Standardquelle oder eine in einer Sandbox eingeschränkte Anwendung erklärt die meisten der verbleibenden Fälle. Das Signal durchläuft einen mehrschichtigen Stapel: den ALSA-Kernel-Treiber, anschließend PipeWire oder PulseAudio und schließlich die Anwendung selbst. Jede Ebene kann das Signal unterbrechen, und das Ergebnis ist stets dieselbe Stille. Die richtige Lösung hängt vollständig davon ab, auf welcher Ebene die Blockade liegt. Diese Anleitung identifiziert diese Ebene und behebt das Problem anschließend sowohl über grafische als auch über Terminal-Schritte. Beginnen Sie mit einem kurzen Mikrofontest oder der Eingangsanzeige auf dem Desktop, um die Hardware zu überprüfen. Stellen Sie anschließend fest, ob Ihre Distribution unter PipeWire oder PulseAudio läuft, da die folgenden Befehle je nach dieser Antwort variieren.
Linux Mikrofon funktioniert nicht: Checkliste für schnelle Lösungen
| ✓ | Führen Sie einen Test mit unserem Mikrofontest oder der Ton-Eingangsanzeige auf dem Desktop durch. |
| ✓ | Schalten Sie den Capture-Kanal in alsamixer wieder ein und erhöhen Sie dessen Pegel. |
| ✓ | Stellen Sie in pavucontrol (oder unter wpctl auf PipeWire) den richtigen Eingang ein. |
| ✓ | Vergewissern Sie sich, dass Ihr Benutzer zur audio-Gruppe gehört. |
| ✓ | Starten Sie den Audio-Dienst neu: systemctl --user restart pipewire pipewire-pulse oder pulseaudio -k. |
Testen Sie Ihr Linux-Mikrofon in weniger als einer Minute
Vergewissern Sie sich, dass das Mikrofon Ton aufnimmt, bevor Sie Einstellungen ändern. Die Behebung des Problems Kein Signal unterscheidet sich grundlegend von der Behebung des Problems Signal vorhanden, aber niemand kann mich hören. Eine Live-Eingangsanzeige liefert die schnellste und zuverlässigste Antwort, da sie in Echtzeit auf Ihre Stimme reagiert. Eine Aufnahme-Wiedergabe-Schleife kann Fehler bei der Geräteauswahl verschleiern; beginnen Sie daher mit einer Pegelanzeige. Öffnen Sie unseren Online-Mikrofon-Test und erteilen Sie den Zugriff, wenn der Browser Sie dazu auffordert. Sprechen Sie nun ganz normal. Wenn sich die Pegelanzeige während des Sprechens bewegt, sind Mikrofon, Treiber und Soundserver in Ordnung. Das Problem liegt dann weiter oben, im Routing oder in einer bestimmten App. Bleibt die Pegelanzeige unverändert, wird das Signal blockiert oder ist der falsche Eingang ausgewählt.
Ihr Desktop stellt das Mikrofon auch nativ zur Verfügung. Öffnen Sie unter GNOME Einstellungen › Ton › Eingang und wählen Sie Ihr Gerät aus; der Eingangspegel-Balken sollte sich bewegen, während Sie sprechen. Unter KDE Plasma öffnen Sie Systemeinstellungen › Audio und beobachten Sie die Pegelanzeige neben dem Aufnahmegerät. Angenommen, der Balken bewegt sich hier, aber eine App nimmt dennoch nichts wahr. Dann haben Sie nachgewiesen, dass der Fehler anwendungsspezifisch und nicht systemweit ist; fahren Sie daher mit den Abschnitten zu Routing und Berechtigungen weiter unten fort. Die Tabelle zeigt die grafischen Stellen, an denen Ihr Desktop das Mikrofon anzeigt, sowie die jeweiligen Anzeigen, die dort zu sehen sind.
| Wo Sie nachsehen sollten | Pfad | Was dies bestätigt |
| GNOME-Eingangsanzeige | Einstellungen › Ton › Eingang | Ob das System ein Signal empfängt und von welchem Gerät |
| KDE-Audio-Bedienfeld | Systemeinstellungen › Audio | Das aktive Aufnahmegerät und dessen App-spezifische Weiterleitung |
| Volume Control | pavucontrol › Eingabegeräte | Stummschaltungsstatus, Verstärkung und der ausgewählte Hardware-Anschluss |
| Registerkarte Aufnahme | pavucontrol › Aufnahme | Welche App von welchem Gerät live aufnimmt |
Machen Sie sich mit Ihrem Soundserver vertraut, bevor Sie Fehlerbehebungsmaßnahmen ergreifen
Linux-Audio ist mehrschichtig aufgebaut, und die richtige Lösung hängt davon ab, welche Ebene fehlerhaft ist. An der Basis steht ALSA, der Treiber auf Kernel-Ebene, der mit der Soundkarte kommuniziert. Darüber läuft ein Soundserver, der Streams mischt und sie zwischen den Anwendungen weiterleitet. Zwei Server dominieren. Moderne Distributionen liefern PipeWire aus. Fedora hat es als Erstes übernommen, und Ubuntu verwendet es seit Version 22.10 standardmäßig. PipeWire nutzt eine Kompatibilitätsschicht namens pipewire-pulse, sodass ältere Tools weiterhin unverändert funktionieren. Ältere Versionen und einige konservative Konfigurationen verwenden nach wie vor PulseAudio. Beide Server setzen auf ALSA auf, und ein stummgeschalteter Kanal in ALSA sorgt bei beiden für Stille.
Stellen Sie zunächst fest, auf welchem Server Sie sich befinden, bevor Sie Zeit mit dem falschen Tool verschwenden. Führen Sie in einem Terminal den Befehl wpctl status aus. Eine übersichtliche Auflistung von Sinks und Sources bedeutet, dass PipeWire aktiv ist. Fehlt der Befehl, befinden Sie sich höchstwahrscheinlich auf PulseAudio; bestätigen Sie dies mit pactl info. Dies ist wichtig, da sich die Befehle unterscheiden. PipeWire wird über wpctl gesteuert, während PulseAudio pactl verwendet. Das grafische Tool pavucontrol funktioniert mit beiden, da pipewire-pulse die gleichen Aufrufe beantwortet. Die folgende Tabelle fasst die wichtigsten Tools und deren jeweilige Funktionen zusammen.
| Tool | Typ | Funktionsweise |
| pavucontrol | Grafisch | Schaltet Eingänge frei, stellt die Verstärkung ein, wählt den Port aus und zeigt die Aufnahmerouten pro Anwendung an |
| alsamixer | Terminal (TUI) | Steuert die ALSA-Karte direkt: Stummschaltung der Aufnahme, Aktivierung der Aufnahme und Hardware-Verstärkung |
| arecord / aplay | Terminal | Listet Aufnahmegeräte auf und nimmt eine Datei direkt über ALSA auf oder gibt sie wieder |
| wpctl | Terminal | Listet PipeWire-Geräte auf, legt die Standardquelle fest und schaltet die Stummschaltung ein oder aus |
Warum ein funktionierendes Mikrofon unter Linux dennoch stumm wird
Ein stummgeschalteter ALSA-Aufnahmekanal ist der Hauptgrund
ALSA steuert jeden Aufnahmekanal unabhängig voneinander, und einer davon kann unterhalb aller anderen stummgeschaltet sein. In diesem Fall zeigt die Desktop-Pegelanzeige Null an, egal wie hoch Sie die Software-Lautstärke einstellen. Diese einzelne Ursache führt zu mehr „defekten“ Linux-Mikrofonen als jeder Hardwarefehler. Die Tücke liegt darin, dass dies im grafischen Mixer oft nicht erkennbar ist. Die Lösung liegt in alsamixer, einem Terminal-Mixer, der den direkten Zugriff auf die Soundkarte ermöglicht. Starten Sie das Programm und drücken Sie F6, um Ihre Soundkarte auszuwählen. Drücken Sie F4, um in die Aufnahmeansicht zu wechseln. Markieren Sie den Capture-Kanal mit den Pfeiltasten. Wenn unter dem Balken MM angezeigt wird, ist er stummgeschaltet; drücken Sie M, um die Stummschaltung aufzuheben. Ein Aufnahmekanal muss zudem aktiviert sein. Drücken Sie Space auf dem ausgewählten Element, bis CAPTURE in roter Schrift angezeigt wird, und erhöhen Sie dann den Pegel mit der Aufwärtspfeiltaste. Viele Laptops bieten hier auch einen Regler namens Internal Mic Boost an, der werkseitig auf Null eingestellt ist. Ihn zu erhöhen kann ein Mikrofon wiederbeleben, das zuvor tot schien.
Falsche Standardquelle und fehlerhaftes Routing
Der Soundserver wählt eine Standardquelle aus, und diese entspricht nicht immer Ihrer Wunschauswahl. Schließen Sie ein USB-Headset, eine Webcam mit integriertem Mikrofon oder ein HDMI-Aufnahmegerät an, und der Server befördert es möglicherweise sofort zur Standardquelle. Routing-Fehler verstecken sich auch in einzelnen Anwendungen. PipeWire und PulseAudio lassen jedes Programm pro Stream von einem anderen Gerät aufnehmen. Eine App kann daher auf eine Quelle ausgerichtet sein, die nichts liefert, während der Systemstandard einwandfrei funktioniert. Die Registerkarte Aufnahme in pavucontrol macht dies direkt sichtbar und listet alle derzeit aufnehmenden Apps sowie die von ihnen verwendeten Geräte auf. Verdächtigen Sie zunächst das Routing, wenn das Mikrofon in einem Programm funktioniert, in einem anderen jedoch nicht. Bluetooth-Headsets bringen eine weitere Komplikation mit sich. Ein Headset im hochwertigen A2DP-Profil hat überhaupt kein Mikrofon. Das System muss es auf das HSP/HFP-Profil umschalten, bevor das Bügelmikrofon verfügbar wird, wobei die Audioqualität dabei sinkt.
Berechtigungen, Gruppen und Sandbox-Apps
Die Zugriffskontrolle sperrt das Mikrofon auf eine Weise, die keine Fehlermeldung hinterlässt. Früher musste ein Benutzer der Gruppe audio angehören, um auf die Audiogeräte zugreifen zu können. Die meisten modernen Desktops regeln dies über die Sitzung, doch bei einer Minimal- oder Serverinstallation kann dies weiterhin erforderlich sein. Sandboxing ist das neuere und größere Problem. Anwendungen, die als Flatpak oder Snap verpackt sind, laufen innerhalb einer Isolationsschicht, die den Zugriff auf das Mikrofon verweigern kann, selbst wenn der Rest des Systems funktioniert. Die App erhält dann ohne Fehlermeldung nur Stille. Sie prüfen und erteilen diese Berechtigungen mit Flatseal, einem grafischen Editor für Flatpak-Portale, oder über das Terminal mit flatpak permissions. Browser fügen eine eigene, separate Ebene darüber hinzu. Eine Website muss unabhängig vom Systemstatus im Browser zugelassen werden. Unsere Anleitungen zu Firefox und Chrome behandeln diese Abfrage im Browser ausführlich.
Behebung des Problems, beginnend mit der häufigsten Ursache
Gehen Sie diese Lösungsansätze der Reihe nach durch. Springen Sie nicht gleich zu den drastischsten Maßnahmen. Die Reihenfolge ist bewusst gewählt. So lassen sich die meisten Fälle zuerst und mit den geringsten Beeinträchtigungen beheben. Das Aufheben der Stummschaltung und das Routing sind zusammen für die meisten Mikrofonausfälle unter Linux verantwortlich. Erst danach eskaliert die Abfolge zum Neustart des Soundservers. Kehren Sie nach jeder Änderung zum Mikrofontest oder zu Ihrer Desktop-Eingangsanzeige zurück. Überprüfen Sie erneut, ob ein Signal vorhanden ist, bevor Sie fortfahren, damit Sie stets wissen, welcher Schritt den Ausschlag gegeben hat.
Stummschaltung aufheben und Routing mit pavucontrol
Installieren und öffnen Sie zunächst pavucontrol, da dieses Programm die häufigsten Fehler grafisch behebt. Wechseln Sie zur Registerkarte Eingabegeräte. Suchen Sie Ihr Mikrofon und vergewissern Sie sich, dass die Stummschalttaste neben dem Pegelregler nicht aktiviert ist. Erhöhen Sie die Eingangslautstärke, falls diese zu niedrig ist. Überprüfen Sie das Dropdown-Menü Port, da Laptops oft sowohl ein internes Mikrofon als auch eine Headset-Buchse unter einem einzigen Gerät zusammenfassen. Öffnen Sie nun die Registerkarte Aufnahme, während Ihre App aktiv ist. Jede aufgelistete App verfügt rechts über eine Geräteauswahl. Weisen Sie die problematische App ausdrücklich dem richtigen Mikrofon zu. Diese einfache Neuzuweisung behebt viele Meldungen vom Typ Funktioniert überall außer hier. Konferenz-Apps verfügen ebenfalls über eine eigene Geräteauswahl; stellen Sie das Gerät daher auch dort ein. Unsere Anleitungen für Zoom und Discord behandeln diese Einstellungen Schritt für Schritt.
Aufnahme in alsamixer aktivieren und dann über das Terminal testen
Wechseln Sie zu alsamixer, wenn der grafische Mixer eine flache Pegelanzeige anzeigt. Befolgen Sie die oben beschriebenen Schritte zum Aufheben der Stummschaltung und zum Aktivieren der Aufnahme: F6 für die Karte, F4 für die Aufnahme, anschließend M und Space auf dem Capture-Kanal. Überprüfen Sie bei aktiviertem Kanal den Hardware-Pfad direkt über ALSA. Führen Sie arecord -l aus, um alle vom Kernel erkannten Aufnahmegeräte aufzulisten. Sollte Ihr Mikrofon hier nicht aufgeführt sein, liegt der Fehler bei einem Treiber- oder Verbindungsproblem, nicht bei den Einstellungen. Wenn es angezeigt wird, nehmen Sie einen kurzen Clip auf und spielen Sie ihn mit arecord -d 5 test.wav && aplay test.wav ab. Wenn Sie Ihre Stimme hören, bestätigt dies, dass der ALSA-Pfad funktioniert, wodurch sich der Fehler auf den Server oder die App eingrenzen lässt. Führen Sie unter PipeWire denselben Vorgang mit wpctl status durch, um die Quell-ID abzurufen, und geben Sie anschließend wpctl set-default <id> sowie wpctl set-mute <id> 0 ein.
Soundserver neu starten, wenn die Anzeige eingefroren bleibt
Angenommen, der Kanal ist nicht stummgeschaltet, die richtige Quelle ist ausgewählt, und die Anzeige bewegt sich dennoch nicht. Der Soundserver ist wahrscheinlich hängengeblieben. Dies ist ein bekannter Zustand nach dem Suspend-Modus, nach dem Hot-Swapping einer USB-Schnittstelle oder nach einem Treiber-Update. Ein Neustart des Servers erzwingt den Neuaufbau des gesamten Audiographen ohne einen Systemneustart. Führen Sie unter PipeWire den Befehl systemctl --user restart pipewire pipewire-pulse wireplumber aus. Führen Sie unter PulseAudio den Befehl pulseaudio -k aus; der Daemon wird daraufhin automatisch neu gestartet. Audio fällt dabei kurz aus. Betrachten Sie dies als Reset-Taste für einen hängenden Stack, nicht als routinemäßigen Schritt. Die folgende Tabelle ordnet häufige Symptome ihren üblichen Ursachen und den schnellsten Abhilfemaßnahmen zu.
| Symptom | Mögliche Ursache | Abhilfe |
| Desktop-Anzeige flach, alle Geräte | Aufnahmekanal in ALSA stummgeschaltet | Capture-Kanal in alsamixer freischalten und aktivieren (M, dann Space) |
| Funktioniert in einer App, in einer anderen jedoch nicht | App-spezifisches Routing zur falschen Quelle | Gerät in pavucontrol › Aufnahme neu zuweisen |
| Mikrofon verschwindet nach dem Anschließen eines Headsets | Standardquelle wurde auf ein neues Gerät verschoben | Quelle mit wpctl set-default oder in pavucontrol festlegen |
| Mikrofon des Bluetooth-Headsets fehlt | Gerät befindet sich im A2DP-Profil | In der Profilliste von pavucontrol zu HSP/HFP wechseln |
| Nur eine App empfängt Stille | Flatpak- oder Snap-Sandbox blockiert das Mikrofon | Zugriff in Flatseal oder über flatpak permissions gewähren |
| Signal kehrt nur nach jedem Neustart zurück | Soundserver nach dem Ruhezustand hängengeblieben | pipewire und wireplumber neu starten oder pulseaudio -k ausführen |
So bleibt Ihr Linux-Mikrofon zuverlässig
Einige Gewohnheiten sorgen dafür, dass das Mikrofon zuverlässig funktioniert, sobald es wieder läuft. Halten Sie das System auf dem neuesten Stand, da PipeWire und WirePlumber häufig Korrekturen für Routing und Bluetooth bereitstellen. Legen Sie das gewünschte Mikrofon als Standardquelle fest, damit ein neu angeschlossenes Headset den Platz nicht unbemerkt übernehmen kann. Überprüfen Sie von Zeit zu Zeit Ihre Flatpak-Berechtigungen und gewähren Sie den Mikrofonzugriff nur Anwendungen, die ihn benötigen. Wenn das Mikrofon in einem Browser, einer Desktop-Anwendung und im Terminal funktionieren muss, testen Sie es an jeder dieser Stellen. Ein Mikrofon, das mit arecord einwandfrei aufzeichnet, kann dennoch eine Ebene höher blockiert sein, etwa in einer Sandbox oder einem Browser-Tab. Das Verhalten variiert zudem je nach Distribution und Desktop-Umgebung, sodass eine Korrektur für Fedora unter Ubuntu unter einem anderen Menüpunkt liegen kann. Wenn Sie zwischen verschiedenen Rechnern wechseln, behandelt unser Chromebook-Leitfaden dieselben Prüfungen unter ChromeOS.
Häufig gestellte Fragen
Wie kann ich feststellen, ob mein System PipeWire oder PulseAudio verwendet?
Führen Sie wpctl status in einem Terminal aus. Eine Auflistung von Sinks und Sources bedeutet, dass PipeWire läuft. Falls der Befehl fehlt, führen Sie pactl info aus und lesen Sie die Zeile Server Name. Fedora und Ubuntu 22.10 oder neuer verwenden standardmäßig PipeWire; ältere Versionen nutzen PulseAudio.
Mein Mikrofon funktioniert mit arecord, jedoch nicht in meinen Anwendungen. Warum?
Eine funktionierende Aufnahme mit arecord beweist, dass der ALSA-Hardwarepfad in Ordnung ist. Der Fehler liegt beim Soundserver oder bei der App. Öffnen Sie die Registerkarte Aufnahme in pavucontrol und weisen Sie der App die richtige Quelle zu. Wenn es sich bei der App um ein Flatpak handelt, überprüfen Sie dessen Mikrofonberechtigung in Flatseal.
Warum wird das Mikrofon meines Bluetooth-Headsets nicht angezeigt?
Der hochwertige A2DP-Modus unterstützt kein Mikrofon. Das Headset muss auf das HSP- oder HFP-Profil umgeschaltet werden, bevor sein Bügelmikrofon verfügbar ist. Öffnen Sie pavucontrol, suchen Sie das Gerät in der Konfigurations- oder Profilliste, und wählen Sie das Headset-Profil aus. Rechnen Sie dabei mit einer Verschlechterung der Audioqualität.
Wie schalte ich das Mikrofon am Terminal wieder ein?
Öffnen Sie unter ALSA alsamixer, drücken Sie F4 für die Aufnahmeansicht, wählen Sie Capture aus und drücken Sie M, um die Stummschaltung aufzuheben. Unter PipeWire suchen Sie die Quell-ID mit dem Befehl wpctl status und führen anschließend wpctl set-mute <id> 0 aus. Ein stummgeschalteter ALSA-Aufnahmekanal ist die häufigste Ursache für einen stummen Eingang.
Wie kann ich Linux-Audio neu starten, ohne den Computer neu zu starten?
Führen Sie unter PipeWire den Befehl systemctl --user restart pipewire pipewire-pulse wireplumber aus. Führen Sie unter PulseAudio den Befehl pulseaudio -k aus, und der Daemon startet sich automatisch neu. Der Ton fällt für eine Sekunde aus, während der Server seinen Graphen neu aufbaut. Verwenden Sie diese Vorgehensweise nur, wenn die Überprüfungen zum Aufheben der Stummschaltung und zum Routing fehlgeschlagen sind.
Testen Sie Ihr Mikrofon
Testen Sie Ihr Mikrofon →