[NJ5x_NJ7xLU, Realtek ALC293, Speaker, Internal] No sound at all (or so KDE "thinks")

[Brian Foster]

This is an odd one (or so it seems to me)...
Sometimes, after booting, my log is filled with messages similar to:

   [ 208.746660] snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=0x20a3b000
   [ 209.758633] snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=0x20a70740
   [ 210.770511] snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=0x20bf0015

See bug #1886626 ("after login to gnome with snd_hda_intel 0000:00:1f.3: No response from codec")
for a very similar problem; or at least the same-ish message.

The KDE volume thingy says there are no audio input or output devices.
I cannot configure anything audio-H/w related with KDE.

HOwEVER, whilst generating this bug report with apport-cli(1), the tests it ran clearly showed
(heard!) the built-in (internal) speakers are working. Intrigued, I tried a wireless Bluetooth
headset (it also worked), a wireless USB headset (also worked), and a wired headset (also worked).
So there *is* sound, but KDE thinks there is no H/w... SOMETIMES.

At other times, everything is fine. There is no known pattern here (e.g., warm- or cold-boot
does not seem to matter, etc.). And then, just to confuse things further, at least once the
system booted up in the KDE-no-sound state (complete with module "No response from codec"),
but later (a few minutes?) began to work; a check of the log (dmesg(1)) showed those messages
had stopped and everything from then on appeared normal. (I'll see if I can find that incident
in the logs, *IF* I can, I'll attach it later.) That "not"-working to working does not usually
seem to happen (that one incident may be the only time it has happened?)

I have no idea if, when in the KDE-no-sound state, if I can control the volume from the computer.
I have also NOT tested the input (microphone(s)) whilst in the KDE-no-sound state, but I presume
it's like the output (works but KDE doesn't know it?).

It sort-of looks like, at the moment, to me, there is sometime amiss in the "kernel sound stuff"
which is having a knock-on effect on the "KDE sound stuff". Apologies I cannot be any more
specific... ;-(

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: alsa-base 1.0.25+dfsg-0ubuntu5
ProcVersionSignature: Ubuntu 5.4.0-53.59-generic 5.4.65
Uname: Linux 5.4.0-53-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.12
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: blf 3447 F.... pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: KDE
Date: Fri Nov 13 00:30:59 2020
InstallationDate: Installed on 2020-10-19 (24 days ago)
InstallationMedia: Kubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
PackageArchitecture: all
SourcePackage: alsa-driver
Symptom: audio
Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH successful
Symptom_Card: Built-in Audio - HDA Intel PCH
Symptom_DevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: blf 3447 F.... pulseaudio
Symptom_Jack: Speaker, Internal
Symptom_PulsePlaybackTest: PulseAudio playback test successful
Symptom_Type: No sound at all
Title: [NJ5x_NJ7xLU, Realtek ALC293, Speaker, Internal] No sound at all
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/16/2020
dmi.bios.vendor: INSYDE Corp.
dmi.bios.version: 1.07.03
dmi.board.asset.tag: Tag 12345
dmi.board.name: NJ5x_NJ7xLU
dmi.board.vendor: Notebook
dmi.board.version: Not Applicable
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: No Enclosure
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnINSYDECorp.:bvr1.07.03:bd07/16/2020:svnNotebook:pnNJ5x_NJ7xLU:pvrNotApplicable:rvnNotebook:rnNJ5x_NJ7xLU:rvrNotApplicable:cvnNoEnclosure:ct10:cvrN/A:
dmi.product.family: Not Applicable
dmi.product.name: NJ5x_NJ7xLU
dmi.product.sku: Not Applicable
dmi.product.version: Not Applicable
dmi.sys.vendor: Notebook

[Brian Foster (blfoster)]

Attached is the output of dmesg(1) shortly after a cold cold-boot when the audio output seems Ok:
The KDE thing knows about the H/W and functions as expected, and all seems happy.
This is mostly for information and comparison with the report's log (when things (well,
at least the module & KDE) didn't work).

By "cold cold-boot" I mean a boot from power OFF ("cold-boot") after being OFF for perhaps
30 minutes ("cold" (i.e., let the system cool down, but I do NOT believe it was "hot")).

As an aside, I tried using `apport-cli -u...' but it decided there was nothing new to report.

Still searching for that incident when things changed from not-all-is-Ok to all-seems-Ok.