Audio, ALSA und PipeWire

USB-Audio kann Abtastrate oder Clock nicht setzen

USB-Audio-Clock- und Abtastratenfehler anhand gemeldeter Formate, Interface-Steuerung und Transportbefunden auswerten, statt globale Rate zu erzwingen.

Auf dieser Seite
  1. Symptome und Geltungsbereich
  2. Mögliche Ursachen
  3. Sicher prüfen
  4. Nächste Schritte nach Befund
  5. Quellen und Prüfung
  6. Verwandte Probleme

Symptome und Geltungsbereich

  • Ein Interface funktioniert mit einer Rate, scheitert aber bei anderer Anwendungsanforderung.
  • Der Kernel meldet cannot set freq oder ungültige Clock-Quelle.

Betroffene Umgebung

USB-Audio-Class-Interfaces mit snd-usb-audio, auch Geräte mit externer Wordclock oder digitalen Sync-Eingängen.

Erkennbare Meldungen (synthetische Beispiele)
usb 1-2: 1:1: cannot set freq 48000 (v2/v3): err -22

Gemeldete Raten, gewählte Clock und Control-Transfer-Kontext vergleichen; dies identifiziert keinen einzelnen Firmwarefehler.

usb 1-2: clock source 41 is not valid, cannot use

Fehlende externe Synchronisation und Modellverhalten prüfen, bevor irgendeine Validierung abgeschaltet wird.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

  • Gewählte Rate oder Kanalaufteilung passt möglicherweise nicht zum gemeldeten Alternate Setting des Interfaces.
  • Eine externe Clock kann fehlen oder nicht synchron sein; Gerätefirmware oder USB-Control-Transferfehler können ähnlich wirken.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

card0/stream0 durch die Stream-Datei des USB-Interfaces ersetzen. Von ALSA gemeldete Formate und Raten lesen; kein PCM wird geöffnet.

cat /proc/asound/card0/stream0

Ergebnis einordnen: Raten und Kanalzahlen des relevanten Wiedergabe- oder Aufnahmeinterfaces verwenden. Gemeldete Formate beweisen weder externe Clock-Synchronisation noch korrekte Firmware.

Prüfschritt 2

USB-Audio- und Controller-Ereignisse nahe dem Ratenwechsel lesen; Journalzugriff kann Rechte benötigen.

journalctl -k -b --no-pager -n 250

Ergebnis einordnen: Ungültige Clock und Set-Frequency-Fehler unterscheiden sich von Last-Xruns. USB-Trennung/Reset spricht für Transportprüfung vor Audio-Tuning.

Nächste Schritte nach Befund

Unterstützte Rate und Clock-Quelle abgleichen

Wenn gewünschte Rate nicht unterstützt wird oder externe Synchronisation fehlt, aktive Audioclients schließen, dokumentierte unterstützte Rate und gültige interne beziehungsweise synchronisierte externe Clock am Interface wählen. Betroffenen Stream neu starten und vergleichen.

Vorsicht: Clock-Wechsel betrifft alle Kanäle und kann angeschlossene Digitalgeräte stören. Ursprüngliche Rate und Sync-Quelle dokumentieren.

Wiederherstellung / Rücknahme: Vorige Rate und Clock-Quelle herstellen, falls Interface oder angeschlossene Geräte Synchronisation verlieren.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

USB-Transport oder dokumentierte Firmwarekorrektur vergleichen

Wenn gültige unterstützte Clock/Rate weiterhin scheitert und das Log USB-Resets zeigt, nach Beenden der Streams bekannt gutes direktes Kabel/Port vergleichen. Bei ratenspezifischem Fehler ohne Transportverlust Herstellerfirmware und Kernel-Quirks für das genaue Interface-Modell prüfen.

Vorsicht: Nicht global 192 kHz erzwingen oder Clock-Prüfung abschalten. Firmware-Updates brauchen stabile Stromversorgung und Hersteller-Rettungshinweise.

Wiederherstellung / Rücknahme: Dokumentierten Port/Kabel herstellen oder einzelnes experimentelles Konfigurationsfragment entfernen. Firmware-Rettung hängt vom Hersteller ab.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Quellen und Prüfung

Diese Anleitung basiert auf Originalquellen von Projekten oder Distributionen und wurde am genannten Datum redaktionell geprüft. Das ist eine Quellenprüfung, kein Nachweis einer auf deiner Hardware reproduzierten Lösung. Log-Beispiele sind synthetische Testdaten. Versionsabhängige Details müssen zur installierten Ausgabe passen.