Bugzilla – Bug 1213187
External microphone does not work on Acer Swift SF514-52T even with snd-hda-intel model=alc255-acer
Last modified: 2023-10-13 09:26:02 UTC
According to aplay -l, my device has “card 0: PCH [HDA Intel PCH], device 0: ALC255 Analog [ALC255 Analog]” as one of the playback hardware devices. By default, the external mic won't show up as an input device at all when plugged. I have to add "options snd-hda-intel model=alc255-acer" to /etc/modprobe.d/alsa-base.conf or /etc/modprobe.d/snd-hda-intel.conf. After adding "options snd-hda-intel model=alc255-acer", then reboot, my external mic shows up correctly. But it only picks up noise. I tried adding "options snd-hda-intel model=alc255-acer,dell-headset-multi", which proved to be working for some users who have the same ALC255 on Acer (https://www.reddit.com/r/openSUSE/comments/yseu43/sound_problems/), but this also doesn't work for me. I updated my Tumbleweed to the latest snapshot.
Created attachment 868131 [details] My alsa-info
Could you give the alsa-info.sh output without model option (i.e. a clean state), too?
Created attachment 868151 [details] My alsa-info without the model option. @Takashi My alsa-info as per requested.
Thanks. Could you try to pass model=1025:1330 to snd-hda-intel module? This applies the same quirk as the machine with PCI SSID 1025:1330 (which is Acer TravelMate X514). The other Acer Swift SF314 was 1025:142b, but this is basically equivalent with model=alc255-acer.
@Takashi Wow, thanks a lot. With "options snd-hda-intel model=1025:1330", my external mic (4 pole 3.5mm jack) works flawlessly. It's dectected as "Headset Microphone - Built-in Audio". I don't know whether this bug should be closed. However, with this model option, "Internal Microphone - Built-in Audio" popups as the input device, which only captures noise. I believe DMIC(my internal mic) won't work with HDA option (options snd-intel-dspcfg dsp_driver=1) anyway.
(In reply to Archer Allstars from comment #5) > @Takashi > > Wow, thanks a lot. With "options snd-hda-intel model=1025:1330", my external > mic (4 pole 3.5mm jack) works flawlessly. It's dectected as "Headset > Microphone - Built-in Audio". > > I don't know whether this bug should be closed. Please keep it opened. I'll prepare a proper patch for the upstream fix, so that it works without the extra option. > However, with this model option, "Internal Microphone - Built-in Audio" > popups as the input device, which only captures noise. I believe DMIC(my > internal mic) won't work with HDA option (options snd-intel-dspcfg > dsp_driver=1) anyway. OK, then we might need another fix. Could you try to use SOF driver by dropping that option? I believe you can pass the equivalent model via hda_model option of snd-sof-intel-hda-common module, instead.
(In reply to Takashi Iwai from comment #6) > Could you try to use SOF driver by dropping that option? > I believe you can pass the equivalent model via hda_model option of > snd-sof-intel-hda-common module, instead. At first, test without hda_model option just to see whether we get a DMIC input.
@Takashi The SOF driver is not supported on the Intel Coffee Lake CPUs (https://github.com/thesofproject/sof/issues/2251). My DMIC is working with the SST driver "options snd-intel-dspcfg dsp_driver=2", but HDMI audio output, which I use all the time, doesn't work with this option. Therefore, I use the HDA driver instead.
(In reply to Archer Allstars from comment #8) > @Takashi > > The SOF driver is not supported on the Intel Coffee Lake CPUs > (https://github.com/thesofproject/sof/issues/2251). Could you give the dmesg output with SOF driver? (Also make sure that you installed sof-firmwrae package.)
Created attachment 868176 [details] My sof-audio dmesg @Takashi The sof-firmware-2.2.5-1.1.noarch package is installed. snd_sof, snd_sof_intel_hda, snd_sof_intel_hda_common, snd_sof_pci, snd_sof_pci_intel_skl, snd_sof_utils, snd_sof_xtensa_dsp are loaded. With the SOF driver, all the audio output and input devices are not available on my device.
So it's now with AVS driver, not really SOF. The firmware for AVS is included in kernel-firmware-sound package, but the firmware for kbl seems missing. Could you try to copy either /lib/firmware/intel/avs/cnl/dsp_basefw.bin.xz to /lib/firmware/intel/avs/kbl/dsp_basefw.bin.xz, and retest? It might be from /lib/firmware/intel/avs/skl/dsp_basefw.bin.xz, instead. Or both might not work.
Created attachment 868179 [details] dmesg with cnl firmware This firmware doesn't work.
Created attachment 868180 [details] dmesg with skl firmware This firmware doesn't work.
@Takashi I tried both the firmware from /lib/firmware/intel/avs/cnl/dsp_basefw.bin.xz and /lib/firmware/intel/avs/skl/dsp_basefw.bin.xz. Both don't work on my device.
Thanks. I'll try to ping Intel people.
I was utterly confused by the messages, but it was actually the result from SOF driver, not AVS driver. And, apparently, the SOF firmware hasn't been released for SKL/KBL. Could you try to pass options snd-intel-dspcfg dsp_driver=4 ? It's not shown in the modinfo output, but it's for using AVS driver.
Created attachment 868205 [details] avs dmesg @Takashi With the AVS driver, all my audio devices are not available.
Thanks. The upstream devs informed about the firmware sources. Below is the compiled firmware binaries. Copy them (dmic-tplg.bin, hda-10ec0255-tplg.bin and hda-8086280b-tplg.bin) into /lib/firmware/intel/avs directory, and reboot/retest.
Created attachment 868215 [details] AVS firmware binaries
Created attachment 868228 [details] dmesg with AVS firmware binaries @Takashi With the AVS firmware binaries copied to /lib/firmware/intel/avs directory in the AVS driver mode, all my audio devices are not available.
Thanks. I forward the results to the upstream devs, and they'll try to fix the issues. They asked whether you can join to the upstream bug tracking for AVS tools. Could you report on the github issues at: https://github.com/thesofproject/avs-topology-xml ??
@Takashi Thanks! I have reported the AVS driver issue on GitHub: https://github.com/thesofproject/avs-topology-xml/issues/20
Great, let's track the AVS driver problem there. Meanwhile I'll try to address the HD-audio codec quirk.
I cooked the fix patch for Realtek codec to enable the headset mic on your machine. I'm building a test kernel with the patch in OBS home:tiwai:bsc1213187 repo. After the build finishes (takes an hour or so), the package will be available at http://download.opensuse.org/repositories/home:/tiwai:/bsc1213187/standard/ Could you give it a try later? You can test it with dsp_driver=1 as you've done beforehand. Once after confirming the patch working, I'll submit it to the upstream and backport to openSUSE kernels.
Created attachment 868340 [details] Fix patch for headset mic
@Takashi Thanks! I added your repo into my system. Which package should I install?
It's a kernel package. Just download kernel-default.rpm, install it manually with zypper install --oldpackage, and boot/test withiout model option.
Created attachment 868364 [details] hda dmesg with patch enabled @Takashi Thanks! I tried the patch. Now, my external mic shows up correctly as my only audio input device without needing to specify the model option. However, it only picks up noise no matter how many times I re-plugged it.
Created attachment 868365 [details] My alsa-info with the patch enabled.
Hmm, if you pass the model option again with that kernel, you'll get the working microphone? If so, I must have picked up a wrong pin or something still missing.
@Takashi With the model option on the patched kernel, my external mic works correctly. But the unusable "Internal Microphone - Built-in Audio" audio input device shows up like it's on the default kernel.
OK, then could you give alsa-info.sh output while you're recording on the external mic?
Created attachment 868368 [details] My alsa-info while recording with a working external mic. @Takashi My alsa-info.sh as per requested.
Thanks. Also, can you give alsa-info.sh output during the (broken) recording from the external mic without model option? So that I do compare 1:1.
Created attachment 868373 [details] My alsa-info output during the (broken) recording from the external mic without model option. @Takashi My alsa-info.sh as per requested.
Thanks! It's still puzzling what makes different. As a blind shot, boot without model option, and try to run hda-verb /dev/snd/hwC0D0 0x1a SET_PIN_WID 0x24 during recording via the headset mic?
Created attachment 868444 [details] My alsa-info while recording and running sudo hda-verb /dev/snd/hwC0D0 0x1a SET_PIN_WID 0x24 @Takashi Here's the terminal return after running sudo hda-verb /dev/snd/hwC0D0 0x1a SET_PIN_WID 0x24 while recording: nid = 0x1a, verb = 0x707, param = 0x24 value = 0x0
I forgot to mention that after running sudo hda-verb /dev/snd/hwC0D0 0x1a SET_PIN_WID 0x24 I still can't get any sound from my external mic. The mic only picks up noise.
OK, could you take alsa-info.sh output again during recording after hda-verb?
Created attachment 868445 [details] My alsa-info output during recording after hda-verb @Takashi My alsa-info.sh as per requested.
Hm, strange, the pin 0x1a still shows the value 0x00: Node 0x1a [Pin Complex] wcaps 0x40048b: Stereo Amp-In .... Pin-ctls: 0x00: VREF_HIZ Could you keep arecord running, and run hda-verb again. Then (while arecord running), check the output of /proc/asound/card0/codec#0, look at the Node 0x1a entry. Isn't the value still updated?
@Takashi When I kept arecord running, and ran hda-verb again, I noticed that the output of cat /proc/asound/card0/codec#0 was changed in Pin-ctls: from: Pin-ctls: 0x00: VREF_HIZ to: Pin-ctls: 0x24: IN VREF_80 Here's the full Node 0x1a output: Node 0x1a [Pin Complex] wcaps 0x40048b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Pincap 0x00003724: IN Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0
OK, so far so good. And even changing this, arecord still doesn't give the sound? The pin is cleared likely by the power-saving feature, and at the next run, it's fully re-initialized. So, for seeing the effect, you'd need to keep arecord running.
@Takashi arecord doesn't give me any sound whether I run hda-verb. The Pin-ctls always stays at Pin-ctls: 0x00: VREF_HIZ whether I record. Only when I run arecord and also running sudo hda-verb /dev/snd/hwC0D0 0x1a SET_PIN_WID 0x24, the Pin-ctls changes to Pin-ctls: 0x24: IN VREF_80.
Well, what I meant is: - Start arecord, keep running - Run hda-verb - Check codec#0 content and see the pin is set to 0x24 - Say something to mic - Run alsa-info.sh to take a shanpshot - Stop arecord Then check the recorded sound. The point is that you must not stop arecord during the whole procedure.
Created attachment 868449 [details] My alsa-info as per requested in comment #45. @Takashi Thanks! My codec#0 pin is set to 0x24. But the arecord file doesn't pick up any sound.
Thanks. I confirmed that everything looks expected, so the pin 0x1a seems to be just a red herring. Then it might be some other missing COEFs that may happen at switching the headset mode. Need to take a deeper look...
Could you try to boot with snd_hda_codec.dump_coef=1 boot option, and get alsa-info.sh outputs again from both working and non-working cases during the recording with the ext mic? It'll include the COEF dumps from the codec, and we can see whether there is any difference there.
@Takashi Thanks! I have a few issues. 1. Since the main kernel on Tumbleweed is updated to Linux 6.4.6-1-default, I can't seem to install the kernel in your repo anymore. 2. How to boot with snd_hda_codec.dump_coef=1 boot option? Is this an optional kernel command line parameter? I tried sudo echo 1 > /sys/module/snd_hda_codec/parameters/dump_coefs, but it doesn't work.
(In reply to Archer Allstars from comment #49) > @Takashi > > Thanks! I have a few issues. > > 1. Since the main kernel on Tumbleweed is updated to Linux 6.4.6-1-default, > I can't seem to install the kernel in your repo anymore. What did you try and which error did you get, more exactly? > 2. How to boot with snd_hda_codec.dump_coef=1 boot option? Is this an > optional kernel command line parameter? I tried sudo echo 1 > > /sys/module/snd_hda_codec/parameters/dump_coefs, but it doesn't work. Yes, snd_hda_codec.dump_coef=1 is a boot kernel command-line option. You can pass a form like $MODULE.$PARAMETER=xxx for modules in the command line, too. This works more conveniently without writing to /etc/modprobe.d/*. The write to the sysfs should work, but in most cases, it's only for root-user; see the file permission.
Created attachment 868622 [details] My alsa-info.sh with snd_hda_codec.dump_coef=1 enabled on kernel Linux 6.4.6-1-default. @Takashi Thanks! > What did you try and which error did you get, more exactly? I add your repo to my system and install kernel-default package with YaST Software Management. After installed the kernel, it presents in the boot menu, but it won't boot due to secure boot, obviously. By disabling secure boot, the kernel disappears from the boot menu. I tried to install the kernel many times with secure boot disabled, but it didn't appear in the boot menu. This wasn't the case before I updated to Linux 6.4.6-1-default. So, I attach alsa-info.sh with snd_hda_codec.dump_coef=1 enabled on kernel Linux 6.4.6-1-default instead.
I forgot to mention that the attached alsa-info.sh with snd_hda_codec.dump_coef=1 above was when I recorded while my external mic was working with options snd-hda-intel model=1025:1330.
Thanks. But could you attach the alsa-info.sh outputs with coef_dump=1 from both working and non-working cases? Then we can compare the COEF values more closely.
Created attachment 868672 [details] My alsa-info.sh when the external mic is working with snd_hda_codec.dump_coef=1 enabled on kernel Linux 6.4.8-1-default. @Takashi My alsa-info.sh as per requested.
Created attachment 868673 [details] My alsa-info.sh when the external mic is not working (without options snd-hda-intel model=1025:1330) with snd_hda_codec.dump_coef=1 enabled on kernel Linux 6.4.8-1-default. @Takashi My alsa-info.sh as per requested.
Could you rather use the kernel in comment 24 as a non-working kernel? That is, install kernel-default-6.4.4-1.1.ge77e54c.x86_64.rpm, boot with it with snd_hda_codec.dump_coef=1, and get alsa-info.sh output during the (non-working) mic input. Then boot the same kernel with he model option, and get the alsa-info.sh output during the working mic-input.
Created attachment 868895 [details] My alsa-info.sh when the external mic is working with snd_hda_codec.dump_coef=1 enabled on kernel-default-6.4.4-1.1.ge77e54c. @Takashi Thanks! And sorry for my late reply. My alsa-info.sh (the model option is enabled) as per requested.
Created attachment 868896 [details] My alsa-info.sh when the external mic is not working with snd_hda_codec.dump_coef=1 enabled on kernel-default-6.4.4-1.1.ge77e54c. @Takashi My alsa-info.sh (without the model option) as per requested.
Thanks! The diff shows: @@ -645,8 +664,8 @@ Node 0x20 [Vendor Defined Widget] wcaps Coeff 0x42: 0x2000 Coeff 0x43: 0xa204 Coeff 0x44: 0x2000 - Coeff 0x45: 0xe489 - Coeff 0x46: 0x0034 + Coeff 0x45: 0xd489 + Coeff 0x46: 0x0074 Coeff 0x47: 0x9472 Coeff 0x48: 0xd049 Coeff 0x49: 0x0149 And the COEF 0x45 and 0x46 are relevant with the headset type (and its detection). Setting 0x45 to 0xd489 should switch to CTIA (iPhone type). Maybe just running the following after plugging the headset mic changes the behavior? hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x45 hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0xd489 But, it's still puzzling why this failed. It likely means that the headset jack detection reported a wrong type. Maybe the missing pin 0x1a vref influences on the behavior? Just a guess. I'm building another test kernel based on the latest stable branch in OBS home:tiwai:bsc1213187-2 repo. Please check with it later.
Created attachment 869066 [details] My alsa-info.sh with snd_hda_codec.dump_coef=1 enabled on kernel Linux 6.4.11-1.1.g56d71a6-default. @Takashi I test the kernel Linux 6.4.11-1.1.g56d71a6-default with snd_hda_codec.dump_coef=1 as per request. I replugged my external mic many times, but it still doesn't work. > Maybe just running the following after plugging the headset mic changes the behavior? > hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x45 > hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0xd489 After running the above commands with `sudo`, my external mic works without any issue.
(In reply to Archer Allstars from comment #60) > Created attachment 869066 [details] > My alsa-info.sh with snd_hda_codec.dump_coef=1 enabled on kernel Linux > 6.4.11-1.1.g56d71a6-default. > > @Takashi > > I test the kernel Linux 6.4.11-1.1.g56d71a6-default with > snd_hda_codec.dump_coef=1 as per request. I replugged my external mic many > times, but it still doesn't work. > > > Maybe just running the following after plugging the headset mic changes the behavior? > > hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x45 > > hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0xd489 > > After running the above commands with `sudo`, my external mic works without > any issue. Thanks for testing. So now one step forward, but still the mystery remains. I'm building yet another test kernel in OBS home:tiwai:bsc1213187-3 repo (now based on 6.5). It's basically with the same quirk patch but with an additional debug print patch that will show kernel messages (indicated with "XXX") at each headset handling. Please get the dmesg output before / after plugging the headset on both working and non-working cases for comparison.
Created attachment 869306 [details] dmesg with kernel Linux 6.5.0-1.g6f613ab-default. @Takashi Thanks for the test kernel! When I plugged my external mic: I compared `dmesg | grep audio` between working and non-working cases, as per requested. But it's identical. I attached the dmesg in this comment.
Created attachment 869307 [details] dmesg with kernel Linux 6.5.0-1.g6f613ab-default when unplugged. When I unplugged my external mic: The dmesg is different as shown in attached file.
Could you gather the same log for the working case (i.e. with the model override), too? Comparison between working and non-working cases is the main interest.
Created attachment 869405 [details] dmesg on a working external mic with model override option, on kernel Linux 6.5.0-1.g6f613ab-default. @Takashi dmesg as per requested.
Thanks! It's even more puzzling, but the problem became clearer. The issue happens when the driver tries to detect the headset mode, and by some reason, when the detection is done from the headphone-only mode to the headset-mode, it probes correctly, but from the none to the headset-mode, it fails. I'll try to ping Realtek people.
Now I got a test patch from Realtek. Another test kernel is being built in OBS home:tiwai:bsc1213187-4 repo. Please give it a try later.
Any chance to check the test kernel?
Created attachment 870145 [details] My alsa-info file on Linux 6.5.2-1.g5784757-default without the model override option. My external mic still doesn't work. @Takashi First, sorry for my very late reply. I totally missed the notify mail. I didn't see the bug update _/\_ I tested the build kernel. It still doesn't work. The only way to make the external mic works is to run this command: sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x45 && sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0xd489
Created attachment 870146 [details] My alsa-info file on Linux 6.5.2-1.g5784757-default without the model override option. This is when it works. @Takashi This is the alsa-info.sh of when it works.
Thanks, I reported back to Realtek devs.