I am having intermittent issues with the output going silent on a USB sound card. Note that this affects both an Apple audio dongle and a Ugreen sound card, two very different chipsets, in the same way, ruling out a hardware issue.

I noticed that unplugging the USB cable and plugging it into another USB socket often fixes the problem, but not always. Rebooting also fixes it temporarily.

Sometimes, I can be listening to audio, and I momentarily pause my video or audio app or even skip/scrub backwards and then the problem will come back and all audio will be silent.

Weirdly, I've noticed that if the Pulseaudio volume control applet is open, the problem for now isn't occurring, and sometimes, if the problem happens and I start that applet, sometimes it fixes the issue (but not always, and sometimes nothing I do in the pulseaudio applet can fix it).

Things I've checked:

  • Pulseaudio is showing correct output device, and the VU meter is showing the audio is playing on it, and it's not muted, but nothing is heard.
  • Alsamixer shows nothing is muted on the relevant audio device
  • It affects various software that plays audio, and when it happens, it appears to happen to all software that is playing to that device.
  • lsusb and similar show nothing odd about the USB device, which is still recognised, and there is nothing in dmesg to indicate a problem with it.
  • Even when the problem of no audio output is occurring, pulseaudio is correctly detecting the device being plugged and unplugged and the type of device it is.

Using Debian stable with Gnome desktop, pulseaudio config is pretty vanilla

1 Answer 1


I discovered the reason it was doing this and a workaround.

It turned out that forcing it to use 44.1KHz/16bit only made the problem go away. The USB audio device was refusing to work using a sample rate higher than 44.1KHz and bit depth of 16 bit, even though the device reports it can work at higher rates and depths (in my case 96KHz and 24bit) - and indeed, it can, just not in this situation.

It appears the reason for the problem was due to issues with USB 1/2 audio devices on USB3 ports, particularly via USB 3 enabled hubs. When using a USB 2 only hub, or plugging directly into a USB 3 port on the host, the problem went away, presumably because it could reserve more bandwidth. When plugging into a hub shared with other devices, sometimes it worked and sometimes it didn't, and this appears related to a problem reserving bandwidth on the host in that configuration. Keeping it to only 44.1KHz/16bit seemed to let it keep working even via the USB 3 hub - seemingly because the USB device goes into an alternate low bandwidth mode where only 44.1KHz/16bit works.

Pulseaudio by default sets a sample rate of 44.1KHz and 16bit, but specifies an "alternate mode" of 48KHz. This is defined in the daemon.conf in /etc/pulse/. This means that while it defaults to 44.1KHz for its link to the device, it can change the sample rate it uses to the device to 48KHz when the source is 48KHz and there are no 44.1KHz sources.

Having the Pulseaudio volume control (pavucontrol) open meant that pavucontrol started monitoring levels, or at least interacting with the sound subsystem. This was preventing pulseaudio switching to 48Khz sample rate, even when playing 48KHz sources, because pavucontrol's monitoring counted as another audio stream and it prevented switching sample rates. It meant that pulseaudio stayed at 44.1KHz and thus the audio output worked.

There were more than one way to successfully work around this:

  1. Set pulseaudio to always use 44.1KHz sample rate by removing the alternate sample rate from daemon.conf (setting it to the same as the default effectively disables it).

  2. Use the USB audio device directly on a host port and not via a USB hub.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .