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/?id=ca169cc2f9e1f8ed9c867b197a49d6dd05e5436d

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

-- 
Jan