[SOLVED] Inbuilt microphone not working Debian Bulleye/sid

[4joeyirosh1]

Hi!I have a HP Pavilion 15-au106TU laptop with Debian Bulleye/sid 64 bit installed.

I am unable to use my inbuilt microphone.Even when I go to Settings ->Input -> Input Device as shown on screenshot below and talk next to my laptop,the meter under Microphone - Built-in Audio doesnt increase in scale when I talk.



Kindly assist.

[FreewheelinFrank]

First

Code: Select all

$ alsamixer

And check the microphone isn't muted (M underneath) then output of

Code: Select all

$ arecord -l

Please.

[4joeyirosh1]

Code: Select all

$ alsamixer

And check the microphone isn't muted (M underneath) then output of

When I run the alsamixer command with my headphones connected to the laptop I get output as shown on screenshot below



When I run the alsamixer command without headphones connected to the laptop (now using internal computer speakers) I get output as shown on screenshot below.I assumed the Microphone settings would still be active as one should be able to use microphone with internal speakers when not using headphones but output is still as below

Code: Select all

$ arecord -l

My output of arecord -l is as below

Code: Select all

arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC295 Analog [ALC295 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

KIndly assist.I am not a alsamixer or hardware expert so please advise on what I should do to get the microphone working

[sunrat]

Those screenshots you posted show the playback controls. Press F4 to view the capture controls.

[4joeyirosh1]

Those screenshots you posted show the playback controls. Press F4 to view the capture controls.

Having gone to F4,I found internal Mic Boost to be 0 and I adjusted to 100 as per screenshot below and saved the configuration with command

Code: Select all

alsactl store

but still I cannot record with the internal microphone.



Despite saving the configuration,everytime I restart the machine the internal mic reverts to zero.How can I resolve these issues?

[sunrat]

Your alsamixer capture levels look ok except when you do get it working that much boost could be scary or even damaging. To check if record is working at the base ALSA level, do a short test recording as described here - https://linuxconfig.org/how-to-test-mic ... cture-alsa . If that works it narrows it down to a PulseAudio problem.

[4joeyirosh1]

Your alsamixer capture levels look ok except when you do get it working that much boost could be scary or even damaging. To check if record is working at the base ALSA level, do a short test recording as described here - https://linuxconfig.org/how-to-test-mic ... cture-alsa . If that works it narrows it down to a PulseAudio problem.

Many thanks sunrat for trying to help me thus far.I have tried following the link you sent me and when I run the commands it seems the wav file isnt being produced so I cant play it.Check output of the commands as below

Code: Select all

# arecord -f S16_LE -d 10 -r 16000 --device="hw:0,0" /tmp/test-mic.wav
Recording WAVE '/tmp/test-mic.wav' : Signed 16 bit Little Endian, Rate 16000 Hz, Mono
arecord: set_params:1349: Channels count non available

# ls -lh /tmp/test-mic.wav
ls: cannot access '/tmp/test-mic.wav': No such file or directory

After doing some research,I found link https://www.spinics.net/linux/fedora/al ... 12829.html and I tweaked the arecord command (not sure if this tweak is relevant for my problem) as below.As the command ran,I tried talking and file was created but when I played the test3.wav file using aplay command,it was just static noise without my voice

Code: Select all

# arecord --device=plughw:0,0 -d 10  --format S16_LE --rate 16000 -c1 /tmp/test3.wav
Recording WAVE '/tmp/test3.wav' : Signed 16 bit Little Endian, Rate 16000 Hz, Mono
root@joey-debian:~# aplay /tmp/test3.wav
Playing WAVE '/tmp/test3.wav' : Signed 16 bit Little Endian, Rate 16000 Hz, Mono

And I am sure my internal microphone is fine as I have a dual boot machine with Windows 10 and from Windows 10 I can use the microphones.

[FreewheelinFrank]

I saw some posts about this card/codec combination that say there is an issue where the internal microphone doesn't work except when a headset with microphone is plugged in (when of course it shouldn't). Might be worth checking out if that happens because there is a fix.

On some recent laptops I believe the microphone is handled by a different driver which requires firmware. This driver may be in the Bullseye kernel, so try installing firmware-sof-signed and see if that fixes it. Won't hurt if it doesn't work.

[4joeyirosh1]

I saw some posts about this card/codec combination that say there is an issue where the internal microphone doesn't work except when a headset with microphone is plugged in (when of course it shouldn't). Might be worth checking out if that happens because there is a fix.

On some recent laptops I believe the microphone is handled by a different driver which requires firmware. This driver may be in the Bullseye kernel, so try installing firmware-sof-signed and see if that fixes it. Won't hurt if it doesn't work.

I have installed firmware-sof-signed and even restarted my machine after installation but problem persists.

[FreewheelinFrank]

Did you try testing the microphone with headphones plugged in? Worth a try.

Sometimes the hardware wrongly reports how it is set up, and the manufacturer hacks the Windows driver so that that software works with it anyway. This means that the Linux driver doesn't, until somebody works out how to hack it to the hardware too. Very frustrating, and usually a matter of trial and error to fix. As this hack has worked for some people with the same set up, give it a go. If the internal mic is mixed up with the headphone jack, there is a way of fixing that. Could be something else though.

[4joeyirosh1]

Did you try testing the microphone with headphones plugged in? Worth a try.

Sometimes the hardware wrongly reports how it is set up, and the manufacturer hacks the Windows driver so that that software works with it anyway. This means that the Linux driver doesn't, until somebody works out how to hack it to the hardware too. Very frustrating, and usually a matter of trial and error to fix. As this hack has worked for some people with the same set up, give it a go. If the internal mic is mixed up with the headphone jack, there is a way of fixing that. Could be something else though.

I have tried testing the microphone with and without the headphones plugged in and still same issue persists.

[FreewheelinFrank]

Does your laptop have a led for the webcam microphone? Might be worth trying this:

https://wiki.archlinux.org/index.php/HP ... x#Mute_LED

It might just be a fix for the led itself, but maybe there is some sort of hardware mute on the mic by default and this will fix it.

I couldn't find the specification for your exact model, but the HP site for a couple of HP Pavilion - 15-au106 models lists the microphone as "dual array digital microphone". I believe the driver for this type of microphone changed in Windows, and Linux is playing catch-up. It may be a case of backporting kernels and firmware until it works, unless anybody else can suggest otherwise.

[4joeyirosh1]

Does your laptop have a led for the webcam microphone? Might be worth trying this:

https://wiki.archlinux.org/index.php/HP ... x#Mute_LED

It might just be a fix for the led itself, but maybe there is some sort of hardware mute on the mic by default and this will fix it.

I couldn't find the specification for your exact model, but the HP site for a couple of HP Pavilion - 15-au106 models lists the microphone as "dual array digital microphone". I believe the driver for this type of microphone changed in Windows, and Linux is playing catch-up. It may be a case of backporting kernels and firmware until it works, unless anybody else can suggest otherwise.

Thanks FreewheelinFrank the mute LED instructions from the link work.

[FreewheelinFrank]

That's good news!

Would you mind doing

Code: Select all

$ lsmod | grep snd

?

Let's see if the firmware made a difference under the hood or if it was just the mute led.

[4joeyirosh1]

That's good news!

Would you mind doing

Code: Select all

$ lsmod | grep snd

?

Let's see if the firmware made a difference under the hood or if it was just the mute led.

I am not a hardware expert so please interpret this output for me

Code: Select all

# lsmod | grep snd
snd_soc_skl           180224  0
snd_soc_hdac_hda       24576  1 snd_soc_skl
snd_hda_codec_hdmi     73728  1
snd_hda_ext_core       36864  2 snd_soc_hdac_hda,snd_soc_skl
snd_soc_sst_ipc        20480  1 snd_soc_skl
snd_soc_sst_dsp        36864  1 snd_soc_skl
snd_hda_codec_realtek   147456  1
snd_soc_acpi_intel_match    45056  1 snd_soc_skl
snd_soc_acpi           16384  2 snd_soc_acpi_intel_match,snd_soc_skl
snd_hda_codec_generic    98304  1 snd_hda_codec_realtek
ledtrig_audio          16384  1 snd_hda_codec_generic
snd_hda_intel          57344  3
snd_intel_dspcfg       28672  2 snd_hda_intel,snd_soc_skl
soundwire_intel        45056  1 snd_intel_dspcfg
snd_soc_core          315392  3 soundwire_intel,snd_soc_hdac_hda,snd_soc_skl
snd_compress           32768  1 snd_soc_core
snd_hda_codec         172032  5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek,snd_soc_hdac_hda
snd_hda_core          110592  8 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_hda_codec_realtek,snd_soc_hdac_hda,snd_soc_skl
snd_hwdep              16384  1 snd_hda_codec
snd_pcm               135168  8 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,soundwire_intel,snd_compress,snd_soc_core,snd_soc_skl,snd_hda_core
snd_timer              49152  1 snd_pcm
snd                   110592  16 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_compress,snd_soc_core,snd_pcm
soundcore              16384  1 snd

[FreewheelinFrank]

I'm not either. I just want to work out if the microphone started working because you fixed the mute led and installed the sof firmware, or just because you fixed the mute led.

I believe it's the latter. There are some kernel modules loaded to do with DSP (digital signal processor), which is how the kernel gets digital microphones to work now, but they seem to use closed-source firmware and not the open-source sof firmware.

https://thesofproject.github.io/latest/ ... ction.html

In other words, it was the mute led fix that worked, and you can uninstall the sof firmware if you want. Probably.

[4joeyirosh1]

Does your laptop have a led for the webcam microphone? Might be worth trying this:

https://wiki.archlinux.org/index.php/HP ... x#Mute_LED

It might just be a fix for the led itself, but maybe there is some sort of hardware mute on the mic by default and this will fix it.

I couldn't find the specification for your exact model, but the HP site for a couple of HP Pavilion - 15-au106 models lists the microphone as "dual array digital microphone". I believe the driver for this type of microphone changed in Windows, and Linux is playing catch-up. It may be a case of backporting kernels and firmware until it works, unless anybody else can suggest otherwise.

Thanks FreewheelinFrank the mute LED instructions from the link work.

I have noticed the solution isnt stable.For instance once I restart the machine,sometimes the microphone works and other times it doesnt.Also,if I test the mic again a few hours after it was working,the mic stops working,

I was hoping for a permanent solution.

[FreewheelinFrank]

Oh, dear.

I assume the mute led isn't on?

Code: Select all

$ pacmd list-sources | grep -e 'index:' -e device.string -e 'name:'

When the mic is working and when it isn't, to see if there is more than one input and if there is which one is default.

Run

Code: Select all

pavucontrol

(Probably same as Gnome- sound- settings).

Check inputs. Make microphone default. Launch sound app. Go to "Recording" "from" (you should see the sound app). Check the source is right.

Edit: Checked on my Gnome system - had to install pavucontrol - similar to Gnome settings but has some extra features.

[FreewheelinFrank]

A few wild guesses and avenues to explore:

HP had a similar problem with these laptops a few years ago:

https://h30434.www3.hp.com/t5/Notebooks ... -p/5855159

Did they hack the Windows driver to fix buggy hardware? Is the Linux driver experiencing the same bugs? Is there an alsa.conf hack to fix them like the led mute hack?

Is the laptop actually behaving as expected, ie muting the mic on inactivity? Does Linux lack a switch in the driver to turn the mic back on again? Is there a .conf fix? Is there a hardware setting in Windows that will carry over into a Linux boot, such as "Don't mute on inactivity"?

I think there is a function button for microphone mute: what happens when you tap that when the microphone isn't working?

[4joeyirosh1]

Oh, dear.

I assume the mute led isn't on?

Code: Select all

$ pacmd list-sources | grep -e 'index:' -e device.string -e 'name:'

When the mic is working and when it isn't, to see if there is more than one input and if there is which one is default.

Run

Code: Select all

pavucontrol

(Probably same as Gnome- sound- settings).

Check inputs. Make microphone default. Launch sound app. Go to "Recording" "from" (you should see the sound app). Check the source is right.

Edit: Checked on my Gnome system - had to install pavucontrol - similar to Gnome settings but has some extra features.

Now something weird is happening.When I go to pavucontrol -> Input devices when my headphones are plugged in I see microphone plugged and internal microphone unplugged as per screenshot below.With this setting,I cannot record sound.



When I remove headphones then,internal microphone is active while microphone is unplugged then I can record sound.I wanted to record sound while headphones still connected to the computer as I could do that yesterday.

When I run the pacmd list-sources | grep -e 'index:' -e device.string -e 'name:' command output is as below

Code: Select all

$ pacmd list-sources | grep -e 'index:' -e device.string -e 'name:'
    index: 0
	name: <alsa_output.pci-0000_00_1f.3.analog-stereo.monitor>
		device.string = "0"
  * index: 1
	name: <alsa_input.pci-0000_00_1f.3.analog-stereo>
		device.string = "front:0"

Output is the same whether I can record sound with headphones off as explained above or when I cannot record sound with headphones plugged in.

This situation keeps changing and getting weirder