You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] Unable to record sound using internal microphone (Thinkbook 13s IML) #2795
After installing Fedora 33 on my laptop (Thinkbook 13s IML) I'm unable to use its internal microphone to record anything. It is recognized by system as "Digital Microphone - sof-hda-dsp", but there is no input from it.
I have tried to record using Sound Recorder (file attached to the ticket in Fedora bug-tracker, see below). There is a high noise in the beginning and after that only silence.
I could confirm that microphone works under Windows 10. Also I can use microphone from plugged in headphones.
Could confirm that the same issue persist in Fedora 33, Fedora 34 Beta, Ubuntu 20.04.
Reproduction Rate
Always.
Expected behavior
Being able to record sound using microphone.
Impact
Unable to use microphone.
Environment
Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
Kernel: 5.10.19-200.fc33.x86_64
SOF: 1.6.1-1
Name of the platform(s) on which the bug is observed.
Platform: Fedora 33
Screenshots or console output
I have reported this bug in Fedora and Ubuntu bug trackers (all logs are attached to them):
[ 12.977340] sof-audio-pci 0000:00:1f.3: DMICs detected in NHLT tables: 2
So it's likely the same issue as on other Lenovo/Acer laptops where they used PDM1 instead of PDM0.
See #2460 (comment) for a tentative solution (BTW issue #2460 is for Lenovo Thinkpad 13s so this bug is likely a duplicate).
If this is the same bug, we're trying to make the PDM1 handling better but this requires kernel+firmware changes. For now manual changes to the topology setup are required.
Thanks @anlar, good to know this is the same issue.
Like I said we don't have a clean way of handling this automatically, we don't have information in ACPI tables to select this configuration, the PDM1 setting is buried inside of a binary blob. We might add a topology override with a kernel flag, or do a deeper surgery using those blobs. It'll take time to fix completely.
Can we use DMI / PCI ID matching to automate the topology selection for those devices? The kernel flag solution is just for debugging. The users are not expected to study things and set it for the normal operation.
@anlar@tlunet can you provide the 'dmidecode' output? I am not a big fan of DMI based quirks but our changes will likely take 3-4 kernel cycles whereas we could update the quirks in the stable kernel much faster. thanks
By the way, my first test was wrong since I had a headphone mic plugged in. Still I put the sof-hda-generic-2ch-pdm1.tplg file in /lib/firmware/intel/sof-tplg/, as described in the temporary solution, but internal mic still don't record sound.
Many thanks for looking into this !
And just in case, here is the dmesg output after removing /lib/firmware/intel/sof-tplg/sof-hda-generic-2ch-pdm1.tplg (got some weird new sound bugs after some time, so I removed it ...).
D'oh? it seems nothing works here, you have tons of IPC errors. Can you try and capture the dmesg from the start of audio probe.
One way to do this is to blacklist snd-sof-pci and doing a dmesg -C; modprobe snd-sof-pci when ready. (if you use a more recent kernel you need to use snd-sof-pci-intel-cnl or -tgl depending on your hardware)
@plbossart can you give me a little bit more detail on how to do it ? I'm still a little bit noob with all that ... I kinda guess what you want me to do, but not so sure ...
I'm using Ubuntu 20.04, latest update. Uname -a gives :
Linux clio 5.8.0-48-generic #54~20.04.1-Ubuntu SMP Sat Mar 20 13:40:25 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
For now, I tried this (massively relying on google's explanations) :
put "blacklist snd-sof-pci" at the end of /etc/modprobe.d/blacklist.conf
run "sudo dmesg -C; sudo modprobe snd-sof-pci"
=> doesn't produce any output, audio out work (I don't have this "dummy" output device anymore), but internal mic still don't (even if I have this Digital Microphone - sof-hda-dsp input device)
Activity
paulstelian97 commentedon Mar 16, 2021
For additional context (I have pulled this from the logs) this is SKL firmware, i7-10510u.
plbossart commentedon Mar 16, 2021
@anar @perexg
from the logs
So it's likely the same issue as on other Lenovo/Acer laptops where they used PDM1 instead of PDM0.
See #2460 (comment) for a tentative solution (BTW issue #2460 is for Lenovo Thinkpad 13s so this bug is likely a duplicate).
If this is the same bug, we're trying to make the PDM1 handling better but this requires kernel+firmware changes. For now manual changes to the topology setup are required.
anlar commentedon Mar 16, 2021
@plbossart Thank you for the link. I have tried to update topology using the one from your comment, and can confirm that my microphone is working now.
plbossart commentedon Mar 16, 2021
Thanks @anlar, good to know this is the same issue.
Like I said we don't have a clean way of handling this automatically, we don't have information in ACPI tables to select this configuration, the PDM1 setting is buried inside of a binary blob. We might add a topology override with a kernel flag, or do a deeper surgery using those blobs. It'll take time to fix completely.
perexg commentedon Mar 16, 2021
Can we use DMI / PCI ID matching to automate the topology selection for those devices? The kernel flag solution is just for debugging. The users are not expected to study things and set it for the normal operation.
plbossart commentedon Mar 16, 2021
@perexg DMI quirks are a management nightmare. I'd rather spend time to make this fully automatic
plbossart commentedon Mar 25, 2021
@anlar @tlunet can you provide the 'dmidecode' output? I am not a big fan of DMI based quirks but our changes will likely take 3-4 kernel cycles whereas we could update the quirks in the stable kernel much faster. thanks
tlunet commentedon Mar 25, 2021
Here you go @plbossart
dmidecode.txt
By the way, my first test was wrong since I had a headphone mic plugged in. Still I put the sof-hda-generic-2ch-pdm1.tplg file in /lib/firmware/intel/sof-tplg/, as described in the temporary solution, but internal mic still don't record sound.
Many thanks for looking into this !
plbossart commentedon Mar 25, 2021
@tlunet can you provide your dmesg log with this file added to /etc/modprobe.d/sof-dyndbg.conf
sof-dyndbg.conf.txt
tlunet commentedon Mar 25, 2021
Sure :
dmesg.txt
EDIT : this file should be ignored, I forgot to remove the .txt extension from the sof-dyndbg.conf file ...
tlunet commentedon Mar 25, 2021
And just in case, here is the dmesg output after removing /lib/firmware/intel/sof-tplg/sof-hda-generic-2ch-pdm1.tplg (got some weird new sound bugs after some time, so I removed it ...).
dmesg.txt
EDIT : after removing the .txt extension from the sof-dyndbg.conf file, here is the correct dmesg output :
dmesg_correct2.txt
plbossart commentedon Mar 25, 2021
D'oh? it seems nothing works here, you have tons of IPC errors. Can you try and capture the dmesg from the start of audio probe.
One way to do this is to blacklist snd-sof-pci and doing a dmesg -C; modprobe snd-sof-pci when ready. (if you use a more recent kernel you need to use snd-sof-pci-intel-cnl or -tgl depending on your hardware)
tlunet commentedon Mar 25, 2021
@plbossart can you give me a little bit more detail on how to do it ? I'm still a little bit noob with all that ... I kinda guess what you want me to do, but not so sure ...
I'm using Ubuntu 20.04, latest update. Uname -a gives :
Linux clio 5.8.0-48-generic #54~20.04.1-Ubuntu SMP Sat Mar 20 13:40:25 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
tlunet commentedon Mar 25, 2021
For now, I tried this (massively relying on google's explanations) :
=> doesn't produce any output, audio out work (I don't have this "dummy" output device anymore), but internal mic still don't (even if I have this Digital Microphone - sof-hda-dsp input device)
ramonvermeulen commentedon Mar 26, 2021
Having the same issue on Ubuntu 20.04 using a Thinkbook 13s.
I tried #2460 (comment) but this solution did not work for me.
plbossart commentedon Mar 29, 2021
then file a different bug with the results of alsa-info and the full dmesg log with dynamic debug enabled as described in #2795 (comment)
keqiaozhang commentedon May 31, 2021
Let's close this issue. @anlar , if needed, please create a new one.
net: pktgen: fix code style (WARNING: Missing a blank line after decl…