Dennis HilkLinux Fix LabDE

Audio, ALSA & PipeWire

USB audio cannot set a sample rate or clock

Interpret USB-audio clock and sample-rate failures using advertised formats, interface controls and transport evidence rather than forcing a global rate.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • An interface works at one rate but fails when an application requests another.
  • The kernel reports cannot set freq or an invalid clock source.

Relevant environment

USB Audio Class interfaces using snd-usb-audio, including devices with external word clock or digital sync inputs.

Recognizable messages (synthetic examples)
usb 1-2: 1:1: cannot set freq 48000 (v2/v3): err -22

Compare advertised rates, selected clock and control-transfer context; this is not enough to identify one firmware bug.

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

Check missing external synchronization and model-specific behavior before disabling any validation.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • The selected rate or channel layout may not match the interface’s advertised alternate setting.
  • An external clock may be missing or unlocked; device firmware or USB control-transfer faults can produce similar errors.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Replace card0/stream0 with the stream file for the USB interface. Read ALSA’s advertised formats and rates; no PCM is opened.

cat /proc/asound/card0/stream0

Interpret the result: Use the relevant playback or capture interface’s rates and channel counts. Advertised formats do not prove external clock lock or firmware correctness.

Check 2

Read USB-audio and controller events near the rate change; journal access may require privileges.

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

Interpret the result: Invalid clock and set-frequency failure are distinct from xruns under load. USB disconnect/reset events suggest a transport check before audio tuning.

Evidence-guided next steps

Match the supported rate and clock source

If the requested rate is unsupported or external sync is absent, close active audio clients, select a documented supported rate and a valid internal or locked external clock in the interface controls. Restart the affected stream and compare.

Precautions: Changing clock affects all channels and can disrupt connected digital equipment. Record the original rate and sync source.

Recovery / rollback: Restore the previous rate and clock source if the interface or connected equipment loses synchronization.

Did this solution help you?

Share this solution#

Compare USB transport or documented firmware fixes

If a valid supported clock/rate still fails and logs contain USB resets, compare a known-good direct cable/port after ending streams. If the fault is rate-specific without transport loss, review vendor firmware and kernel quirks for the exact interface model.

Precautions: Do not globally force 192 kHz or disable clock validation. Firmware updates need stable power and vendor recovery instructions.

Recovery / rollback: Restore the recorded port/cable or remove the single experimental configuration fragment. Firmware recovery depends on the vendor.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.