Bug 207329
|
Description
anonymous272912
2020-04-17 18:59:37 UTC
Could you upgrade only the kernel while keeping the rest and confirm that the problem appears? If yes, please upload alsa-info.sh outputs taken from those working and non-working states again. But use attachments, not paste here. Hi, thanks for the quick response. I upgraded the kernel within Debian 9 to the backported kernel and I can no longer hear any sound. I attach the alsa-info outputs. Thanx in advance for your help, Ralf Created attachment 288573 [details]
kernel 4.19.0-0.bpo.8-686-pae / no sound
Created attachment 288575 [details]
kernel 4.9.0-12-686-pae / sound output is working (internal speaker)
I narrowed it a little bit further down: With kernel 4.16.0-0.bpo.2-686-pae I get sound. Kernel 4.19.0-0.bpo.8-686-pae with option snd_hda_intel.power_save=0 does not produce any sound. Created attachment 288583 [details]
Kernel 4.16.0-0.bpo.2-686-pae / sound output is working (internal speaker)
Created attachment 288585 [details]
kernel 4.19.0-0.bpo.8-686-pae with snd_hda_intel.power_save=0 / no sound
Thanks. Through a quick glance, I can't find anything obvious between those two outputs. At least, the codec setup looks identical in both of them. How is the exact problem? Is only the playback from the speaker is broken. Both the headphone and the speaker don't work? The mixer and the recording? I tried more kernel versions: 4.18.0-0.bpo.1-686-pae: sound (internal speaker) is working. 4.19.0-0.bpo.8-686-pae: Internal speaker: no sound Headphone plug laptop: sound is working Headphone plug docking station: sound is working Created attachment 288587 [details]
kernel 4.18.0-0.bpo.1-686-pae: internal speaker are working
Thanks. It's still not clear what broke, though... Any chance to try a recent upstream kernel? Also I see a sign of Oops there. Is it a relevant one? Also, try to pass snd_hda_intel.model=nofixup option. On the older 4.18 kernel both headphone connectors work as well. The nofixup option did not help. The Oops happened only with the test 4.16 kernel. The screen froze and keyboard did not seem to work yet the sound output worked (I logged into the machine from another one with ssh and tested it.). I will try a newer kernel. By the way, I did not get recording to work (with arecord) - on both the 4.18 and 4.19 kernel. If I enable "Loopback mixing" I can hear the mic on the speaker and adjust it with the "Mic" mixer. Yet the output with arecord is a flat line (zeros). I switched to my Debian 10 installation and tried the newest backported kernel. That does not solve my problem. 5.4.0-0.bpo.4-686-pae: Internal speaker: no sound Headphone connection laptop: sound is working Headphone connection docking station: sound is working Mic connection: Can be heard with loopback and adjusted with "Mic" mixer, but yields no recorded data (only zeros). Created attachment 288589 [details]
kernel 5.4.0-0.bpo.4-686-pae / no sound with internal speakers
Thanks for the quick testing. Hm, that's tough, then. Since there is no change in the proc output, could you enable the COEF dumping via snd_hda_codec.dump_coef=1 option, and take again alsa-info.sh output on both working and non-working kernels? This might give some difference in the hidden registers. There is a difference in the coeff output:
Kernel 4.18.0-0.bpo.1-686-pae (internal speaker work / sound is working):
Coeff 0x07: 0x1040
Kernel 4.19.0-0.bpo.8-686-pae (internal speaker silent / no sound):
Coeff 0x07: 0x3050
Created attachment 288591 [details]
Kernel 4.18.0-0.bpo.1-686-pae: internal speaker work / output incl. coeff
Created attachment 288593 [details]
Kernel 4.19.0-0.bpo.8-686-pae: internal speaker silent / output incl. coeff
OK, then could you run the below in the non-working system? hda-verb /dev/snd/hwC0D0 0x1a SET_COEF_INDEX 0x07 hda-verb /dev/snd/hwC0D0 0x1a SET_PROC_COEF 0x1040 I tried patch_realtek.c from linux-4.18.20 and took the rest of /sound/pci/hda from linux-4.19.98 and compiled the modules. It exchanged snd-hda-codec-realtek.ko and now the internal speaker work in the 4.19 kernel. The diff between two patch_realtek.c files is rather big, so I do not know what the problems is. I just tried the two hda-verb commands in the non-working system (with original snd-hda-codec-realtek.ko) and the internal speaker were turned on immediately and start to work. Good to hear!
I guess just changing the below should fix the missing COEF setup. That's the only significant change between 4.18 and 4.19 wrt your device:
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -1694,7 +1694,7 @@ static void alc260_fixup_fsc_s7020(struct hda_codec *codec,
const struct hda_fixup *fix, int action)
{
struct alc_spec *spec = codec->spec;
- if (action == HDA_FIXUP_ACT_PRE_PROBE)
+ if (action == HDA_FIXUP_ACT_PROBE)
spec->init_amp = ALC_INIT_NONE;
}
@@ -1702,7 +1702,7 @@ static void alc260_fixup_fsc_s7020_jwse(struct hda_codec *codec,
const struct hda_fixup *fix, int action)
{
struct alc_spec *spec = codec->spec;
- if (action == HDA_FIXUP_ACT_PRE_PROBE) {
+ if (action == HDA_FIXUP_ACT_PROBE) {
spec->gen.add_jack_modes = 1;
spec->gen.hp_mic = 1;
}
Yes, this patch fixes the problem. Thanks a lot! OK, that's a good step forward. Now I found the real culprit, and the proper fix patch is below. Please try it instead of the previous patch. Created attachment 288597 [details]
Fix patch for S7020
Created attachment 288599 [details]
(Corrected) patch for fixing S7020 regression
A minor correction to the one above...
I have now tried the new patch (attachment 288599 [details] / 16:14:25) and it works great.
The internal speaker now work as expected. Very nice - great job!
By the way, the first patch (from 15:37:22) did not work perfectly. I realized that only after a reboot. I needed to unload the automatically loaded snd-hda-intel and reload it to make the sound work.
The (up to today unknown to me) problem with the mic connectors remains.
(The spoken sound can be heard if loopback is enabled and its volume adjusted with the "Mic" mixer, but it yields no recorded data (only zeros)).
Is that hard to debug? I have the same problem on another machine, too, where it is really relevant to me.
Looking at alsa-info.sh output, "Capture Switch" is off and volume 0 by some reason for both two capture streams. Isn't this the cause? Try the following: amixer -c0 set Capture cap +20dB amixer -c0 set Capture,1 cap +20dB BTW, the fix patch was now submitted to upstream and merged to sound git tree. It'll be included in 5.7-rc3 (too late for rc2), then backported to stable trees later. Created attachment 288685 [details]
alsa-info with volumes high / no recording
The fix to restore the internal speaker's sound output still works flawlessly.
Once more, thanks a lot for your work.
Recording does not work though (but did not work with the older kernels either).
The amixer commands do not help.
Attached is an alsa-info output with high volume settings and loopback enabled.
I guess with these settings it should work.
The mic sound can be heard clearly through the headphones, but arecord does only yield zeros.
If I disable auto-mute I can hear the microphone both through the headphones and the internal speakers.
Any ideas?
No idea what's wrong. At least, the secondary capture stream is still muted, so you should try to set capture flag there. And make sure that you're recording from the right stream, e.g. check both streams via arecord with the raw ALSA device, pasuspender -- arecord -fcd -Dhw:0,0 -vv foo.wav pasuspender -- arecord -fcd -Dhw:0,1 -vv bar.wav If the loopback is working, it means that the signal is processed inside the codec, so the rest should be the capture stream setup. Thanks a lot for your superb help: The information that a capture stream is still muted helped. I explicitely played with mute and unmute and it instantaneously worked. In the end, the mic capture problem might have been a "user error" and not a kernel / driver problem. However, I am still wondering a bit what was wrong the last time since the first capture stream is the relevant one and not the second one ... But I will not look into that. So for me everything is fine now. |