Bug 219697

Created attachment 307490 [details]
alsa-info.sh output, before suspend (with coef)

Sound works properly from both the internal speakers and 3.5mm headphone output prior to suspend. But after resuming from suspend, the sound from the 3.5mm (wired) headphone output is no longer stereo. It sounds like mono when each channel is tested individually, but actually one channel is also out of phase. This is on a Dell Venue 11 Pro 7130 (with i3-4020Y CPU).

It only affects 3.5mm headphone output; internal speakers continue to work properly. The problem only occurs after resuming from deep suspend, not s2idle. (I use deep suspend (kernel option mem_sleep_default=deep) because it consumes too much battery in s2idle standby.) It does not return to normal until a reboot.

It also makes no difference whether using Pipewire or Pulse Audio, and all programs using sound are affected, including GNOME or KDE Plasma's Settings "Test Speakers".

I used these tests to reproduce the problem at the ALSA level, all using 3.5mm headphone output:
speaker-test -c2 -t wav
 - Before suspend "front left" is heard in left ear and "front right" is heard in the right ear as expected.
 - After resuming from suspend, "front left" is heard in both the left & right ear, and "front right" is heard in both left and right ear.
 
play a mono wav file (so that the same sound in both channels to test for out of phase i.e. cancellation):
aplay /usr/share/sounds/alsa/Noise.wav
 - Before suspend, this is heard in both left and right ears as expected.
 - After suspend, this is heard only very quietly and only in the right ear, i.e. consistent with out-of-phase cancellation.

I originally reported this bug at OpenSUSE (ref: https://bugzilla.opensuse.org/show_bug.cgi?id=1235686) where Takashi Iwai has kindly assisted.

A diff of alsa-info.sh output (with dump_coef) before and after deep suspend showed the following COEF discrepancies:

-    Coeff 0x06: 0x2100
+    Coeff 0x06: 0x2104

-    Coeff 0x0d: 0x2800
+    Coeff 0x0d: 0x2840

-    Coeff 0x16: 0x2250
+    Coeff 0x16: 0x0250

-    Coeff 0x43: 0x9614
+    Coeff 0x43: 0xa614

-    Coeff 0x46: 0x3004
+    Coeff 0x46: 0x0004

When the problem is occurring (after every resume from deep suspend) I can fix it by setting the COEF back to its pre-suspend values with hda-verb. I observed that COEF index 0x16 does not retain its value.

So I performed some testing using the following commands (excluding COEF index 0x16) when the headphone output is in the bad state and it successfully fixes it every time:

hda-verb /dev/snd/hwC1D0 0x20 SET_COEF_INDEX 0x06
hda-verb /dev/snd/hwC1D0 0x20 SET_PROC_COEF 0x2100

hda-verb /dev/snd/hwC1D0 0x20 SET_COEF_INDEX 0x0d
hda-verb /dev/snd/hwC1D0 0x20 SET_PROC_COEF 0x2800

hda-verb /dev/snd/hwC1D0 0x20 SET_COEF_INDEX 0x43
hda-verb /dev/snd/hwC1D0 0x20 SET_PROC_COEF 0x9614

hda-verb /dev/snd/hwC1D0 0x20 SET_COEF_INDEX 0x46
hda-verb /dev/snd/hwC1D0 0x20 SET_PROC_COEF 0x3004


Testing them one-by-one showed that just COEF index 0x0d on its own will also fix it, i.e. these commands alone also work:

hda-verb /dev/snd/hwC1D0 0x20 SET_COEF_INDEX 0x0d
hda-verb /dev/snd/hwC1D0 0x20 SET_PROC_COEF 0x2800

Also I found that setting 0x0d to 0x2840 will recreate the problem anytime, including without suspending.

The internal speakers output continued to work normally and was unaffected by any of the above tests.