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.
signature.asc
Description: This is a digitally signed message part.
