[gentoo-user] No sound after resuming from hibernation

[gentoo-user] No sound after resuming from hibernation

[Dr Rainer Woitok]

Greetings,

immediately after a reboot I can clearly hear the white noise created by
executing

   $ aplay /usr/share/sounds/alsa/Noise.wav
   Playing WAVE '/usr/share/sounds/alsa/Noise.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
   $

and the "lsmod" command lists quite a few loaded sound modules.   Howev-
er, after resuming from hibernation  the same "aplay" command still pro-
duces the same line on standard output, returns the same exit code of 0,
but does not produce any sound.  And the "lsmod" command still lists the
same loaded modules.

Anybody having a clue what's happening here?

And while we are at it: At

   https://wiki.gentoo.org/wiki/Kernel/Gentoo_Kernel_Configuration_Guide

the authors flatly state "Note that ALSA is an exception to the suggest-
ed scheme of not building things as modules: ALSA is actually much easi-
er to configure  when the  components  are modular."  without giving any
further expanation.   What precisely am I  giving away  when I build the
ALSA stuff directly into the kernel?

Sincerely,
  Rainer

Re: [gentoo-user] No sound after resuming from hibernation

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2130 bytes --]

On Sunday, 3 January 2021 15:59:49 GMT Dr Rainer Woitok wrote:
> Greetings,
> 
> immediately after a reboot I can clearly hear the white noise created by
> executing
> 
>    $ aplay /usr/share/sounds/alsa/Noise.wav
>    Playing WAVE '/usr/share/sounds/alsa/Noise.wav' : Signed 16 bit Little
> Endian, Rate 48000 Hz, Mono $
> 
> and the "lsmod" command lists quite a few loaded sound modules.   Howev-
> er, after resuming from hibernation  the same "aplay" command still pro-
> duces the same line on standard output, returns the same exit code of 0,
> but does not produce any sound.  And the "lsmod" command still lists the
> same loaded modules.
> 
> Anybody having a clue what's happening here?
> 
> And while we are at it: At
> 
>    https://wiki.gentoo.org/wiki/Kernel/Gentoo_Kernel_Configuration_Guide
> 
> the authors flatly state "Note that ALSA is an exception to the suggest-
> ed scheme of not building things as modules: ALSA is actually much easi-
> er to configure  when the  components  are modular."  without giving any
> further expanation.   What precisely am I  giving away  when I build the
> ALSA stuff directly into the kernel?
> 
> Sincerely,
>   Rainer

It used to be the case modules were probed/reloaded by 'alsactl init' when 
initialising the audio card.  If built in the kernel binary the command 
couldn't do this.  Troubleshooting required monitoring responses and errors as 
the modules were being loaded and consequently the devs were not very 
forthcoming with solutions, unless you had your alsa drivers compiled as 
modules.

I had a laptop a long time ago, which I had to reboot into MSWindows to get 
the audio to work again.  Using alsamixer and alsactl in Linux would not wake 
up the card, no matter what I tried.  One day this problem went away after a 
kernel update, so I attributed it to a buggy linux audio driver.

Some modules show power saving features with 'modinfo', which may alter the 
card's behaviour if they can be switched off.

I suggest you use alsactl init before and after and compare the output between 
a working and non-working state, to try to isolate the problem.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] No sound after resuming from hibernation

[Dr Rainer Woitok]

Michael,

On Sunday, 2021-01-03 16:13:35 +0000, you wrote:

> ...
> It used to be the case modules were probed/reloaded by 'alsactl init' when 
> initialising the audio card.  If built in the kernel binary the command 
> couldn't do this.

Thanks for this background information :-)

Am I correct in asuming  that this more or less  is still true,  and I'd
rather continue to build sound support as modules?

> ...
> I suggest you use alsactl init before and after and compare the output between 
> a working and non-working state, to try to isolate the problem.

Erm ... good suggestion:

$ alsactl init
alsa-lib /var/tmp/portage/media-libs/alsa-lib-1.2.3.2-r1/work/alsa-lib-1.2.3.2/src/ucm/main.c:983:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -2
Found hardware: "HDA-Intel" "Realtek ALC269VC" "HDA:10ec0269,15586508,00100202 HDA:80862809,80860101,00100000" "0x1558" "0x6508"
Hardware is initialized using a generic method
/usr/share/alsa/init/default:102: value write error: Input/output error
/usr/share/alsa/init/default:263: value write error: Input/output error
/usr/share/alsa/init/default:263: value write error: Input/output error
$ echo $?
99
$

Running "sudo alsactl init" produces exactly the same result.  So what's
broken here?  Or what to try next?

Sincerely,
  Rainer

Re: [gentoo-user] No sound after resuming from hibernation

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1970 bytes --]

On Sunday, 3 January 2021 17:12:20 GMT you wrote:
> Michael,
> 
> On Sunday, 2021-01-03 16:13:35 +0000, you wrote:
> > ...
> > It used to be the case modules were probed/reloaded by 'alsactl init' when
> > initialising the audio card.  If built in the kernel binary the command
> > couldn't do this.
> 
> Thanks for this background information :-)
> 
> Am I correct in asuming  that this more or less  is still true,  and I'd
> rather continue to build sound support as modules?

I can't confirm this, but in my case I've been building alsa drivers as 
modules ever since.


> > ...
> > I suggest you use alsactl init before and after and compare the output
> > between a working and non-working state, to try to isolate the problem.
> 
> Erm ... good suggestion:
> 
> $ alsactl init
> alsa-lib
> /var/tmp/portage/media-libs/alsa-lib-1.2.3.2-r1/work/alsa-lib-1.2.3.2/src/u
> cm/main.c:983:(snd_use_case_mgr_open) error: failed to import hw:0 use case
> configuration -2 Found hardware: "HDA-Intel" "Realtek ALC269VC"
> "HDA:10ec0269,15586508,00100202 HDA:80862809,80860101,00100000" "0x1558"
> "0x6508" Hardware is initialized using a generic method
> /usr/share/alsa/init/default:102: value write error: Input/output error

The above on my system refers to headphone control:

CTL{name}="Headphone Playback Switch",CTL{do_search}=="1", \
  CTL{values}="on"

> /usr/share/alsa/init/default:263: value write error: Input/output error
> /usr/share/alsa/init/default:263: value write error: Input/output error

This refers to recording volume:

CTL{name}="Capture Volume",CTL{do_search}=="1", \
  CTL{write}!="$env{cvolume}",CTL{values}="$env{cpercent}"

is your user a member of the audio group?

Are you able to unmute your settings, if muted, with alsamixer?

I recall an older alsa bug with some realtek driver, whereby to get their 
audio back some users had to suspend to RAM first.  :-/  Yes, I know, it 
sounds like cargo-culting, but apparently it worked for them.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] No sound after resuming from hibernation

[Dr Rainer Woitok]

Michael,

On Sunday, 2021-01-03 18:43:34 +0000, you wrote:

> ...
> > /usr/share/alsa/init/default:102: value write error: Input/output error
> 
> The above on my system refers to headphone control:
> 
> CTL{name}="Headphone Playback Switch",CTL{do_search}=="1", \
>   CTL{values}="on"
> 
> > /usr/share/alsa/init/default:263: value write error: Input/output error
> > /usr/share/alsa/init/default:263: value write error: Input/output error
> 
> This refers to recording volume:
> 
> CTL{name}="Capture Volume",CTL{do_search}=="1", \
>   CTL{write}!="$env{cvolume}",CTL{values}="$env{cpercent}"

Same here.

> is your user a member of the audio group?

$ id
uid=1000(rainer) gid=1000(rainer) groups=1000(rainer),7(lp),10(wheel),18(audio),19(cdrom),27(video),80(cdrw),85(usb),100(users),106(lpadmin),250(portage),272(plugdev),997(scanner)
$

> Are you able to unmute your settings, if muted, with alsamixer?

After running "alsactl init"  the only settings muted in "alsamixer" are
"Master" and "Headphone", and yes, I can unmute both by pressing the "m"
key.  But this does neither bring back sound nor does it change the out-
put from another "alsactl init".

> I recall an older alsa bug with some realtek driver, whereby to get their 
> audio back some users had to suspend to RAM first.  :-/  Yes, I know, it 
> sounds like cargo-culting, but apparently it worked for them.

Oh well, is there a replacement for ALSA?   Can I use "pulseaudio" with-
out ALSA?

Sincerely,
  Rainer

Re: [gentoo-user] No sound after resuming from hibernation

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

On Monday, 4 January 2021 10:33:47 GMT Dr Rainer Woitok wrote:

> Oh well, is there a replacement for ALSA?   Can I use "pulseaudio" with-
> out ALSA?
> 
> Sincerely,
>   Rainer

Without the alsa kernel driver available, the pulseaudio mixing controls won't 
be able to talk to the hardware.

Does 'alsactl init' report something different after a cold reboot when sound 
works as expected, as opposed to after hibernation?

Does your audio driver have a power saving function?  modinfo will show this 
and you can enable/disable it, via /etc/modprobe.d/ - see here for more info:

https://wiki.gentoo.org/wiki/Power_management/Soundcard

Do you have alsasound service configured to run at boot?  If so, does sound 
return if you restart the service after hibernation?

Another thought:  could it be the default audio device changes after restoring 
from hibernation?  What I mean is, if your audio device has PCM and HDMI 
outputs, it may be the order is reversed for some unknown reason.  If so, you 
should still have sound on one of the outputs.  In this case, you could 
hardcode the order of the audio devices in /etc/asound.conf so the desired 
audio card output is always the default.

If none of the above provide a solution, then it must be some MoBo/driver bug, 
which will need more involved debugging with the latest testing kernel 
version.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]