Internal Microphone Not Working on OpenSUSE (Only External Mic Detected)

As I said, I got no URL link of any kind. I did notice some sort of message that flashed briefly and then disappeared before I could read it, and I wonder if that’s why i got no link.

I chose to save the information locally, but the file is 45 K in size.

@ CousinRicky The URL will not disappear unless the bash shell crashes. Perhaps you did not understand the command /usr/sbin/alsa-info.sh is to be run in a bash shell? Let me know if you need an explanation there.

As for the file being saved locally and 45k in size. That is no problem. openSUSE has a specific web site where such files can be uploaded for sharing. You can simply copy it and upload it to: https://paste.opensuse.org/

Maybe give it one to three months before you select for it to be deleted.

I did run it in bash (I figured so from the .sh suffix), and I never saw any URL anywhere at any time. My paste is at: https://paste.opensuse.org/pastes/5b7a487fc595

Thank you for the susepaste output you provided in a later post.

You audio input is CLEARLY detected. Look at this from arecord in the script:

**** List of CAPTURE Hardware Devices ****
card 0: sofhdadsp [sof-hda-dsp], device 0: HDA Analog (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 6: DMIC (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 7: DMIC16kHz (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Capture devices may mean your microphones in this case. Ok?

However when I look at your mixer settings, you should be capturing audio ok. I note:

Simple mixer control 'Mic Boost',0
  Capabilities: volume
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 3
  Front Left: 1 [33%] [10.00dB]
  Front Right: 1 [33%] [10.00dB]
.
Simple mixer control 'Capture',0
  Capabilities: cvolume cswitch
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 63
  Front Left: Capture 63 [100%] [30.00dB] [on]
  Front Right: Capture 63 [100%] [30.00dB] [on]
.
Simple mixer control 'Dmic0',0
  Capabilities: cvolume cswitch
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 70
  Front Left: Capture 55 [79%] [5.00dB] [on]
  Front Right: Capture 55 [79%] [5.00dB] [on]
Simple mixer control 'Dmic1 2nd',0
  Capabilities: cvolume
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 70
  Front Left: Capture 50 [71%] [0.00dB]
  Front Right: Capture 50 [71%] [0.00dB]
.
Simple mixer control 'PGA2.0 2 Master',0
  Capabilities: cvolume
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 80
  Front Left: Capture 50 [62%] [0.00dB]
  Front Right: Capture 50 [62%] [0.00dB]

So that all looks ok.

I believe your internal mic (which I assume you are attempting to get working) is Dmic0 and Dmic1 (as seen in the mixer), and corresponds to Card-0 Device-6 and Card-0 Device-7.

Lets check the Dmic0 which is Card-0 Device-6 (ie hw:0,6) to see if it will record.

To check that I need to see the number of channels in that device. So send this command in a bash shell for card-0 device 6:

arecord -D hw:0,6 --dump-hw-params

check its contents and note what I type below.

The previous ‘dump-hw-params’ command argument I specified will let you know how many channels and the available format. For the test I propose you need to know that.

In the example I provide below I will assume that S16_LE is an available format and I will assume that hw:0,6 is 2 channels (in contrast, on my Lenovo is is 4 channels), so correct the command below as necessary. Note -d 10 indicates the record duration and it is saved to test_mic.wav. After a 10 second recording test, play back and see if any audio recorded.

So send this command (including your edits instead) in a bash shell.

arecord -D hw:0,6 -d 10 -f S16_LE -c 2 -r 48000 test_mic.wav

The replay ‘test_mic.wav’ with a media player. You may have to turn up the volume very high to hear the recording.

If you hear audio, my suspicion is your pulseaudio or pipewire is not correctly configured to record with the app you are trying. Have you tried installing and running pavucontrol to assess if the microphone was properly selected for your app?
.
If you still have no success, can you then run the script with root permissions, where if you run with root permissions, it will populate the ‘dmesg’ at the bottom of the script. ie:
sudo /usr/sbin/alsa-info.sh
and as before, post a link to the script output. Hopefully that will not be necessary.

Good luck!

Again, thank you for the detailed analysis. There is always something new to learn about.
It seems that the kernel detects the microphone correctly, but the higher layer of the system - PulseAudio is unable to cooperate. If I open pavucontrol, I see one input microphone, but it is an unplugged microphone. If I plug in my headphones, it starts capturing but… The built-in microphone is gone.

Fortunately, I don’t rely on built-in microphone on this system, but I can imagine that it is a showstopper for many others. :frowning:

I’m looking forward to the upcoming immutable version of Leap. I would just rollback the system a few versions back.

I don’t known much about your desktop (KDE? Gnome? other?) nor the configuration you have applied in pavucontrol, as they can affect the behaviour in regards to the internal mic.

Did you run sudo /usr/sbin/alsa-info.sh a second time, like I think I suggested (? - maybe i am thinking of another thread) . By running with ‘sudo’ the dmesg will be populated and we can look for error messages there.

Also, perhaps you could open the pavucontrol (PulseAudio Volume Control) application. Go to the “Configuration” tab. Look for a profile for your laptop’s sound card. There might be multiple profiles. Try switching to different profiles (e.g., “Analog Stereo Duplex,” “Pro Audio”, or other) to see if any of them correctly enable the internal microphone to work with you desktop.
.
Go to the “Input Devices” tab. Even if it says “unplugged,” check if the internal mic is muted. Sometimes, unmuting it can make it work.

You could try sending this command to see what it tells you about your laptop’s microphone under pulseaudio:
pactl list cards

Check to see there if pulse audio lists any microphones. As to whether there is anything desktop specific, given I did not see any desktop information provided, I can not comment as to whether that has any relevance.

In regards to pavucontrol’s configuration profiles, I think this command will list them, such that you could copy and paste the output here to share:

pactl list cards | awk '/Name: alsa_card.pci-0000_00_1f.3/,/Active Profile/' | grep -A20 'Profiles:'

The alsa_card.pci-0000_00_1f.3/ in the above works on some laptops, and it works on my Lenovo (different model from your device), but … it may not work for yours. < unsure > … The command does NOT fix anything. It simply should , if it works, list the same profiles that you see in pavucontrol.

I confess i don’t know much about pulse audio nor pipewire, so we are delving into an area where my knowledge is not all that strong. Others on this forum likely have stronger knowledge than mine here. … I basically fell behind when pulse audio and pipewire came out, and I am ‘playing catchup’.
.

This is my output. It seems to be the same as the graphical pavucontrol.

pactl list cards | awk '/Name: alsa_card.pci-0000_00_1f.3/,/Active Profile/' | grep -A20 'Profiles:'
	Profiles:
		input:stereo-fallback: Stereo Input (sinks: 0, sources: 1, priority: 51, available: no)
		output:stereo-fallback: Stereo Output (sinks: 1, sources: 0, priority: 37868, available: yes)
		output:stereo-fallback+input:stereo-fallback: Stereo Output + Stereo Input (sinks: 1, sources: 1, priority: 5151, available: yes)
		off: Off (sinks: 0, sources: 0, priority: 0, available: yes)
	Active Profile: output:stereo-fallback+input:stereo-fallback

That was the intent. I wanted to see the content of pavucontrol … which based on that I believe it is something like this:

  • Stereo Output
  • Stereo Output + Stereo Input
  • Stereo Input (unplugged)(unavailable)
  • Off
    … when your external microphone is not plugged in.

I am scratching my head to understand again what your issue may be? I believe you note your external microphone works.

Are you unable to get your internal microphone to work no matter which of the two selections (Stereo Output and Stereo Output + Stereo Input) you use in pavucontrol?

On my Lenovo X1 Carbon generation-9 with “Stereo Output” selected my internal microphone works.

This laptop isn’t my daily driver, so it isn’t a big issue for me, but it’s a miracle to me.

Like 2 or 3 weeks ago, it stopped working. The installation of the Leap is almost one year old. I don’t install new software or change settings. Only maintenance upgrades like once a week. That’s why I’m wondering what problem it might be.

If I plug my USB hub with external microphone and external camera with another microphone, it’s visible, but not the internal one.

Not sure, but maybe internal-microphone-suddenly-requires-pro-audio is related?

You nailed it! After the upgrade, my microphone is detected again!

Thank you everybody for the support! You are awesome!

I had been trying to parse all this out, then one day, my mic was back. I don’t know what happened, but my best guess is one of the daily updates broke the mic, then a later update fixed it.

My understanding is sometime back (years back) there was a decision made to create alsa-ucm-conf as a separate package from alsa-lib , which was driven by the need to manage hardware-specific audio configurations more efficiently.

Instead of embedding these “use case” profiles—which define how to set up a sound card for tasks like playback or recording—directly within the core alsa-lib package, they were moved to a dedicated, easily updatable package.

I believe the idea was that this allows new hardware support to be added or existing profiles to be fixed by simply updating the alsa-ucm-conf package, without the need to recompile or update the entire alsa-lib stack.

The separation decouples the core audio library from the ever-changing landscape of hardware configurations, leading to a more modular, maintainable, and responsive system for Linux audio.

However - I also suspect a recent mistake was made in an alsa-ucm-conf which broke the functionality in some microphones, and a subsequent alsa-ucm-conf update fixed that.

At least, that is my speculation / understanding here.

1 Like

I think you are right in that understanding.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.