After upgrading to Kubuntu 25 (KDE Plasma), my laptop’s internal digital microphone was detected at the ALSA and PipeWire levels but did not appear in KDE Plasma’s audio input dropdowns or in browser applications. As a result, the microphone did not work when joining a Zoom meeting, even though audio capture itself was functional. This post documents how I identified the microphone using pw-cli, why it worked in Audacity before it appeared in KDE Plasma, and why the device only became visible once WirePlumber policy was fully active (i.e., how to get a digital microphone to show up in the desktop dropdowns). Observed behavior
This indicated that the microphone worked at the driver level, but was not being advertised correctly to the desktop environment.
Key discovery
The internal microphone was first positively identified by inspecting the PipeWire graph directly:
pw-cli list-objects | grep Node pw-cli info 59
Node 59 corresponded to:
alsa_input.pci-0000_06_00.6.HiFi__Mic1__source
This node represented the internal stereo digital microphone (AMD ACP6x DMIC).
Using pw-cat against this node confirmed that audio capture worked, even though the device was not visible in KDE Plasma’s UI.
Important clarification
pw-cli did not enable the microphone or make it appear in KDE Plasma.
It only:
Desktop enumeration and device visibility are handled by WirePlumber, not pw-cli.
Root cause
During the upgrade process, the audio stack entered a partially installed / partially active state:
Without WirePlumber:
Resolution
Once PipeWire and WirePlumber were fully installed and running in a logged-in user session, KDE Plasma correctly enumerated the internal digital microphone:
sudo apt install pipewire pipewire-pulse wireplumber pipewire-tools
After logging back into KDE Plasma, PipeWire policy was applied correctly and the microphone became visible to the desktop.
GUI confirmation (how to know you’re actually done)
At the end of this process, all of the following should be true: 1. Audacity
This confirms PipeWire input is functioning end-to-end.
2. Volume Control (pavucontrol)
This confirms the device is visible at the session-policy level.
3. System Settings → Sound
This confirms KDE Plasma enumeration is working.
4. Browser test
This confirms browser + portal visibility (required for Zoom, Meet, etc.).
5. System tray indicator
This confirms full desktop integration.
Takeaway
- arecord -l showed an ACP6x DMIC capture device early on
- ALSA-level recording worked
- Audacity could record audio using the “Pulse” backend
- KDE Plasma audio settings did not list the internal microphone
- Browsers / Zoom could not see or select a microphone
This indicated that the microphone worked at the driver level, but was not being advertised correctly to the desktop environment.
Key discovery
The internal microphone was first positively identified by inspecting the PipeWire graph directly:
pw-cli list-objects | grep Node pw-cli info 59
Node 59 corresponded to:
alsa_input.pci-0000_06_00.6.HiFi__Mic1__source
This node represented the internal stereo digital microphone (AMD ACP6x DMIC).
Using pw-cat against this node confirmed that audio capture worked, even though the device was not visible in KDE Plasma’s UI.
Important clarification
pw-cli did not enable the microphone or make it appear in KDE Plasma.
It only:
- Exposed an already-existing PipeWire node
- Allowed direct verification that the microphone worked
Desktop enumeration and device visibility are handled by WirePlumber, not pw-cli.
Root cause
During the upgrade process, the audio stack entered a partially installed / partially active state:
- PipeWire components were present
- Some installs failed or were incomplete
- WirePlumber (the PipeWire session manager) was missing, not running, or not running in a valid user session
Without WirePlumber:
- PipeWire nodes may exist
- Applications like Audacity may still access them
- KDE Plasma cannot enumerate or advertise them
- Browsers and conferencing apps see no microphone
Resolution
Once PipeWire and WirePlumber were fully installed and running in a logged-in user session, KDE Plasma correctly enumerated the internal digital microphone:
sudo apt install pipewire pipewire-pulse wireplumber pipewire-tools
After logging back into KDE Plasma, PipeWire policy was applied correctly and the microphone became visible to the desktop.
GUI confirmation (how to know you’re actually done)
At the end of this process, all of the following should be true: 1. Audacity
- Select the Pulse / PipeWire audio host
- Enable Silent Monitoring
- Speak into the microphone
- You should see live audio levels moving, even before recording
This confirms PipeWire input is functioning end-to-end.
2. Volume Control (pavucontrol)
- Open Volume Control
- Go to the Recording tab
- The internal microphone should appear
- You should see active level meters when speaking
This confirms the device is visible at the session-policy level.
3. System Settings → Sound
- Open System Settings → Sound
- Go to Recording Devices
- The Digital Microphone / Internal Mic should be listed
- Selecting it should show input level activity
This confirms KDE Plasma enumeration is working.
4. Browser test
- Visit:
👉 https://www.onlinemictest.com/ - Allow microphone access
- You should see the microphone detected and audio levels responding
This confirms browser + portal visibility (required for Zoom, Meet, etc.).
5. System tray indicator
- A microphone icon should appear in the notification area
- It should sit alongside the speaker, battery, network, and Bluetooth icons
- The icon should activate when the mic is in use
This confirms full desktop integration.
Takeaway
- The internal digital microphone was never disabled
- It existed at ALSA and PipeWire levels before it appeared in the UI
- pw-cli was essential for diagnosing, not enabling, the device
- KDE Plasma audio enumeration depends on WirePlumber policy running in a user session
- GUI confirmation is the final proof that the audio stack is fully functional