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