AUKEY USB Webcam Microphone Not Working on Pop!_OS / Linux: Diagnosis and a Practical Fix

For a while I had a strange issue with my AUKEY USB webcam: the video side worked perfectly, but the microphone side behaved inconsistently. The system could see the microphone, applications could list it, and sometimes it would even work for a short time, but then audio would disappear again.

This post documents exactly how the problem appeared on my machine, what I found while debugging it, and what I ended up doing on Pop!_OS 22.04 to get it under control.

Quick Summary

Webcam brand: AUKEY
USB identity / detected model: PC-LM1E (1d6c:0103)
OS: Pop!_OS 22.04
Video worked fine, microphone did not
The mic was visible in the system, but audio input would randomly stop
The most likely cause was a mix of:
unstable USB audio behavior
hardware mic gain being changed at runtime
USB autosuspend / power management interfering with the audio side

How the Problem Showed Up

These were the main symptoms on my system:

The webcam video always worked.
The microphone appeared in Linux audio settings.
Applications could detect the microphone device.
But actual audio input was unreliable or missing.
Sometimes the input level meter in GNOME / Pop!_OS Sound settings would not move at all.
Sometimes the mic would briefly work and then stop again.
Restarting pipewire, pipewire-pulse, and wireplumber would sometimes bring it back.
The ALSA microphone capture gain would occasionally drop to 0%.

So this was not a simple “the device is not detected” issue. The device was detected. The audio path was just not stable.

Where the Problem Appeared

The issue showed up in multiple places:

In system audio settings, the input level meter would sometimes stay completely flat.
In browser-based meeting apps, the microphone could appear selected but still send no sound.
At the ALSA layer, the microphone capture gain could silently reset.
In PipeWire, the source could exist but still produce no usable samples.

I also tested OBS virtual camera behavior during the same troubleshooting session. OBS Virtual Camera showed up in Firefox but not in Edge. That turned out to be a separate browser / WebRTC issue. The main problem here was the unstable microphone behavior.

Verifying That the Hardware Was Actually Detected

The first step was to confirm that Linux could really see the device.

lsusb showed:

ID 1d6c:0103 PC-LM1E PC-LM1E

arecord -l showed a capture device:

card 1: PCLM1E [PC-LM1E], device 0: USB Audio [USB Audio]

PipeWire also created a source:

alsa_input.usb-PC-LM1E_PC-LM1E_PC-LM1E-02.mono-fallback

That immediately ruled out the simplest case where Linux cannot see the microphone at all.

First Important Finding: The Mic Gain Kept Dropping to Zero

One of the most useful checks was:

amixer -c 1

At some points, this showed:

Simple mixer control 'Mic',0
Mono: Capture 0 [0%] [0.00dB] [on]

So even though the microphone existed and was enabled, its capture gain had dropped to zero.

That meant the device could look fine from the outside while still behaving like a silent microphone.

A temporary fix was:

amixer -c 1 sset Mic 80% cap

This often brought the microphone back, but the problem could still return later.

Second Important Finding: Restarting PipeWire Could Bring the Mic Back

At various points, this command sequence helped:

systemctl --user restart pipewire pipewire-pulse wireplumber

This strongly suggested that:

the microphone capsule was not simply dead
the USB audio interface was not permanently broken
the audio session or device state could get stuck
restarting the user audio services forced the device to be enumerated again

In other words, this looked more like an unstable interaction between the webcam’s USB audio interface and the Linux audio stack than a fully dead microphone.

Third Important Finding: USB Autosuspend Was Enabled

This turned out to be the most convincing root-cause candidate.

When I checked the USB power control state for the device:

cat /sys/devices/pci0000:00/0000:00:08.1/0000:0a:00.3/usb5/5-1/power/control

the result was:

auto

And the autosuspend delay was:

cat /sys/devices/pci0000:00/0000:00:08.1/0000:0a:00.3/usb5/5-1/power/autosuspend_delay_ms

which returned:

So the device was eligible for USB power saving after 2 seconds.

That lined up very well with the observed behavior: the webcam video side could stay fine, while the microphone side would become unreliable after idle periods or after the audio graph was rebuilt.

Most Likely Technical Explanation

My conclusion was roughly this:

The webcam video path is fine.
The microphone is exposed through snd-usb-audio.
PipeWire sees this source as supporting hardware volume and hardware mute control.
That means runtime audio changes can directly affect the device’s real mic gain.
On top of that, USB autosuspend appears to make the audio side unstable.

So this does not look like:

a simple one-click settings mistake
a totally dead microphone capsule
a case where Linux cannot see the device

It looks much more like this particular webcam’s USB audio implementation behaves poorly under Linux power management and modern user-session audio handling.

The Fix I Applied

The practical solution for me had two layers.

1. Disable USB Autosuspend for This Device

I added a persistent udev rule for this USB device:

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1d6c", ATTR{idProduct}=="0103", TEST=="power/control", ATTR{power/control}="on"

Rule file:

/etc/udev/rules.d/99-aukey-usb-audio-power.rules

This forces power/control=on whenever the device is connected.

To reload and apply it:

sudo udevadm control --reload
sudo udevadm trigger --attr-match=idVendor=1d6c --attr-match=idProduct=0103

Then verify:

cat /sys/devices/pci0000:00/0000:00:08.1/0000:0a:00.3/usb5/5-1/power/control

Expected output:

on

2. Keep the Mic Gain Alive in User Session

Because the issue was not only about autosuspend, I also added a small user service that periodically restores the mic settings.

The logic is simple:

amixer -c 1 sset Mic 80% cap
pactl set-source-volume alsa_input.usb-PC-LM1E_PC-LM1E_PC-LM1E-02.mono-fallback 100%
pactl set-source-mute alsa_input.usb-PC-LM1E_PC-LM1E_PC-LM1E-02.mono-fallback 0

I ran that through a systemd --user service so that the mic gain would be corrected automatically if some application or audio layer pushed it into a bad state again.

You can check the service with:

systemctl --user status keep-aukey-mic-alive.service

Useful Recovery Commands

If the microphone stops working again, these commands may help.

Restore ALSA mic gain

amixer -c 1 sset Mic 80% cap

Restart the user audio stack

systemctl --user restart pipewire pipewire-pulse wireplumber

Restore the PipeWire source volume

pactl set-source-volume alsa_input.usb-PC-LM1E_PC-LM1E_PC-LM1E-02.mono-fallback 100%

Is This a Hardware Problem or a Software Problem?

My best answer is: both, but not in the usual way.

It does not look like a pure hardware failure, because:

the mic is detected
it can sometimes produce audio
restarting the audio stack can bring it back

It also does not look like a pure software misconfiguration, because:

the problem can return even after settings are corrected
USB power state appears to matter
the device’s own hardware gain can change unexpectedly

So the most accurate description is probably this:

the webcam’s microphone side is unstable under Linux
Linux power management and session audio handling make the issue more visible
the device is not fully dead, but it is not behaving robustly either

What I Would Recommend to Others

If your USB webcam video works but the microphone is unreliable, I would suggest this order:

Verify that the device is detected:

lsusb
arecord -l
pactl list short sources

Check the ALSA mic gain with amixer.
If the gain is 0%, raise it manually.
Restart pipewire, pipewire-pulse, and wireplumber.
Check whether USB autosuspend is enabled.
If it is, disable autosuspend for that device.
If the problem still comes back, add a small user service that keeps the gain and mute state in a known-good configuration.

Final Takeaway

In my case, the key issue was not that Linux completely failed to see the AUKEY webcam microphone. The real problem was that the webcam showed up correctly but its microphone path behaved inconsistently under Linux.

The most useful clues were:

the device existed in ALSA and PipeWire
the mic gain sometimes dropped to zero
restarting PipeWire could revive it
USB autosuspend was enabled

The most practical fix ended up being:

disable USB autosuspend for this device
keep a recovery path for PipeWire restarts
optionally run a small watchdog to keep mic gain alive

If you have a similar webcam and the video works while the mic randomly dies, it is worth trying these steps before assuming the microphone hardware is completely dead.