Cannot get Lenovo P520/Realtek ALC662 (rev 3) to produce sound
Hello list,
this time within wider circle (and with more experience so far).
I am seeking for help with shiny new Lenovo P520 machine that only lacks one thing for me to be entirely happy it. I believe this is relatively a new batch -- intentionally mentioning it since the topic of this very machine appears to be a settled case already: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
With newest BIOS, running the most recent kernel from Fedora Rawhide (but I did try 5.5.10 kernel from Fedora 30 as well), booted via UEFI (incl. secure boot), the only way to get it to produce any sound whatsoever is to manually load snd-pcsp [*1].
With that done, virtual terminal starts to beep as expected (as in printf '\a'), I am able to run "beep" program, and even "aplay -D hw:pcsp /usr/share/sound/alsa/*.wav" is producing the respective sounds, despite suffering from surrounding noise[*]. That validates that basic function of the built-in speaker works just fine (and previously, it was validated under Windows that it worked just fine).
As the linked commit indicates, the proper model parameter to snd-hda-audio module is dual-codecs. I've tried that, and a handful of other models, to no avail. I considered the possibility the problem is just that I cannot work with "mute" state properly, so tried everything I could (incl. alsaunmute), again, without any change. Next dimension to the matrix was attaching external speaker to the front connector. Nothing has helped.
Comparing outputs from alsa-info.sh for both states, "no model specified" and "dual-codecs" specified, there was no observable change other than this sole "model" parameter not/being (null). I am not sure whether this means this particular predefined quirk was applied properly, or the same observation is to be expected in general. Note that said quirk is, IIUIC, normally hooked onto the presence of "Subsystem: Lenovo Device 1036" (as in from lspci), and it is what this machine assuredly satisfies.
I am attaching the output from the plain/default case, and looking forward to being able to move at least a bit with this.
I'd be fine, for the time being, to use the sketched "PC speaker" workaround, if only it wasn't spoiled with so much noise/hum (no audio connector was used at that time). But that won't solve the urging general teleconferencing problem of these days, apparently.
[*1] at a matter of fact, even it should play no role here, there was a change between this 5.7.0.rc7 kernel and the other tested, 5.5.10, in that the respective (another, IIRC) module got loaded automatically in the latter/older, whereas it needed to be loaded manually with the former/newer
[*2] perhaps resembled https://bugzilla.redhat.com/show_bug.cgi?id=1660581 that I found when trying to do an extensive search around similar problems
Thanks
Ok, I have some new progress to report, since best way to get out of laziness is to open the can publicly, right? :-)
On 5/31/20 4:05 PM, Jan Pokorny wrote:
As the linked commit indicates, the proper model parameter to snd-hda-audio module is dual-codecs. I've tried that, and a handful of other models, to no avail. I considered the possibility the problem is just that I cannot work with "mute" state properly, so tried everything I could (incl. alsaunmute), again, without any change. Next dimension to the matrix was attaching external speaker to the front connector. Nothing has helped.
So now, with dual-codecs model explicitly requested, I finally tried to attach the external speaker to the rear sound out connector (this location is not very convenient for me, that's why I was skipping it so far!), and to my surprise, the long awaited sound is here. Awesome!
But that's just one point out of many, since it seems things are rather crazy, especially:
When I have this rear connector in use, and attach headphones to the front "headset" (per depiction) connector, pavucontrol changes the output from "Line Out (plugged in)" to "Headphones (plugged in)" -- leaving the former still "plugged in" -- which read "Headphones (unplugged)" before, but its respective slider effectively also controls line out, and nothing is going out of the headphones on said front jack.
Neither an isolated microphone with rear mic jack or front headset jack nor a proper single-jack headset with this front jack connector works. "Analog Stereo Duplex" mode being selected was double-checked for that. Tested with observing no indication of signal in pavucontrol, assuming this is reliable way to test.
So, what can be done about getting these work?
* front panel headset jack - headphones mode only - headset
* rear mic jack for the mic
* internal speaker without said noise, just in case it is ever needed as a backup ... it definitely worked rather well under Windows
Where these tested at the time of the original fixup being prepared? Is it possible anything has changed hardware-wise since then? What diagnostics can I provide to push this towards resolution?
Also, what may still be slightly unsettling, I don't see the string "HDAudio-Lenovo-DualCodecs" present with said fixup anywhere, should I?
Thanks
On 5/31/20 6:07 PM, Jan Pokorny wrote:
So, what can be done about getting these work?
- front panel headset jack
- headphones mode only - headset
rear mic jack for the mic
internal speaker without said noise, just in case it is
ever needed as a backup ... it definitely worked rather well under Windows
Ah, this last one can be marked as checked, suddenly noticed that graphical terminal generated "nice" alarm just resounded unexpectedly :-)
Sadly, this snd_pcsp appears to be a prerequisite and it is not loaded automatically in this Fedora Rawhide installation and with this audio HW (~ no out of the box experience, not sure where to forward this after more testing, cannot immediately as it cannot be unloaded for being in use).
The noisy sound will only appear when a separate (not present unless snd_pcsp is loaded) PC-Speaker (Master) channel gets unmuted. Maybe I even confused cause and effect about this, it's all, well, confusing, so sorry if that was the case.
Problem solved!
The solution was as simple as installing alsa-ucm package. (Extra credit to Mark Pearson for pointing some recent changes in that project out to me.)
Color me very embarrassed.
Perhaps the intention of keeping the package set minimal backfired (EDIT: nope, nothing seems to be actively associated with that package incl. opt-in ones), but frankly, have never needed this package, not even heard about it before.
I wonder why there are no pointers anywhere, at least in alsa-info.sh output that would perhaps make the case clear for the experts amongst you. Or somewhere else, where it could be raised as a suggestion:
It appears as if you have a card/coded that relies on UCM for it to be used to the full extent, and UCM does not appear to be installed. Try installing that software, commonly packaged as alsa-ucm. Having it up-to-date may also help.
[if not anything else, perhaps at least this makes it on-topic for the list]
Perhaps even close relationship between alsa-utils and alsa-ucm, on the suggests/recommends level or something like that?
On the whole it seems more enlightenment towards users is advisable, on more than one front, mainly for the ignorants like me :-)
Now, all seems to be working:
On 6/1/20 11:36 PM, Jan Pokorny wrote:
On 5/31/20 6:07 PM, Jan Pokorny wrote:
So, what can be done about getting these work?
- front panel headset jack
- headphones mode only - headset
"mic only" mode doesn't seem to work, but it was perhaps never intended, since there is always:
- rear mic jack for the mic
that works as well
- internal speaker without said noise, just in case it is
ever needed as a backup ... it definitely worked rather well under Windows
irrelevant now, either do not load (default as mentioned) or do not enable in the mixer/pavucontrol.
Ah, this last one can be marked as checked, suddenly noticed that graphical terminal generated "nice" alarm just resounded unexpectedly :-)
Sadly, this snd_pcsp appears to be a prerequisite and it is not loaded automatically in this Fedora Rawhide installation and with this audio HW (~ no out of the box experience, not sure where to forward this after more testing, cannot immediately as it cannot be unloaded for being in use).
negative, the prerequisite was this alsa-ucm package
The noisy sound will only appear when a separate (not present unless snd_pcsp is loaded) PC-Speaker (Master) channel gets unmuted. Maybe I even confused cause and effect about this, it's all, well, confusing, so sorry if that was the case.
There was definitely a lot of confusion on my side.
Sorry about that and have a great day
On Tue, 02 Jun 2020 13:59:31 +0200, Jan Pokorny wrote:
I wonder why there are no pointers anywhere, at least in alsa-info.sh output that would perhaps make the case clear for the experts amongst you. Or somewhere else, where it could be raised as a suggestion:
It appears as if you have a card/coded that relies on UCM for it to be used to the full extent, and UCM does not appear to be installed. Try installing that software, commonly packaged as alsa-ucm. Having it up-to-date may also help.
Unfortunately it's not so trivial for now. The UCM is optional, and there is no specific indicator that mandates UCM profile from the driver side, so far.
We might need to introduce some more hints for UCM profile, e.g. via ALSA component string.
thanks,
Takashi
Dne 02. 06. 20 v 13:59 Jan Pokorny napsal(a):
Problem solved!
The solution was as simple as installing alsa-ucm package. (Extra credit to Mark Pearson for pointing some recent changes in that project out to me.)
Color me very embarrassed.
Perhaps the intention of keeping the package set minimal backfired (EDIT: nope, nothing seems to be actively associated with that package incl. opt-in ones), but frankly, have never needed this package, not even heard about it before.
I wonder why there are no pointers anywhere, at least in alsa-info.sh output that would perhaps make the case clear for the experts amongst you. Or somewhere else, where it could be raised as a suggestion:
It appears as if you have a card/coded that relies on UCM for it to be used to the full extent, and UCM does not appear to be installed. Try installing that software, commonly packaged as alsa-ucm. Having it up-to-date may also help.[if not anything else, perhaps at least this makes it on-topic for the list]
Perhaps even close relationship between alsa-utils and alsa-ucm, on the suggests/recommends level or something like that?
On the whole it seems more enlightenment towards users is advisable, on more than one front, mainly for the ignorants like me :-)
Thanks for this analysis. Please, create a Fedora bug for this for the further analysis / fixes. The alsa-ucm is installed for the workstation GUIs:
https://pagure.io/fedora-comps/blob/master/f/comps-f33.xml.in
See "Fedora Workstation", "LXDE Desktop", "LXQt Desktop" etc. All depends on the "multimedia" package group which contains alsa-ucm.
Anyway, it's a distro problem, so move the discussion to the right place.
Jaroslav
Hello,
On 6/5/20 11:44 AM, Jaroslav Kysela wrote:
Dne 02. 06. 20 v 13:59 Jan Pokorny napsal(a):
Problem solved!
The solution was as simple as installing alsa-ucm package. (Extra credit to Mark Pearson for pointing some recent changes in that project out to me.)
Color me very embarrassed.
Perhaps the intention of keeping the package set minimal backfired (EDIT: nope, nothing seems to be actively associated with that package incl. opt-in ones), but frankly, have never needed this package, not even heard about it before.
I wonder why there are no pointers anywhere, at least in alsa-info.sh output that would perhaps make the case clear for the experts amongst you. Or somewhere else, where it could be raised as a suggestion:
It appears as if you have a card/coded that relies on UCM for it to be used to the full extent, and UCM does not appear to be installed. Try installing that software, commonly packaged as alsa-ucm. Having it up-to-date may also help.
[if not anything else, perhaps at least this makes it on-topic for the list]
Perhaps even close relationship between alsa-utils and alsa-ucm, on the suggests/recommends level or something like that?
On the whole it seems more enlightenment towards users is advisable, on more than one front, mainly for the ignorants like me :-)
Thanks for this analysis. Please, create a Fedora bug for this for the further analysis / fixes. The alsa-ucm is installed for the workstation GUIs:
https://pagure.io/fedora-comps/blob/master/f/comps-f33.xml.in
See "Fedora Workstation", "LXDE Desktop", "LXQt Desktop" etc. All depends on the "multimedia" package group which contains alsa-ucm.
Anyway, it's a distro problem, so move the discussion to the right place.
Yes, filed this wish to have actual functional dependencies more visible at the distro _and_ deployment level against Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1846787
Thanks everyone for the inputs so far
participants (3)
-
Jan Pokorny -
Jaroslav Kysela -
Takashi Iwai