[alsa-devel] Since kernel-2.6.32 alsactl thinks my sound card is "Unknown"

[Raymond Yau]

2010/9/2 Pacho Ramos <pacho at condmat1.ciencias.uniovi.es>

> El jue, 02-09-2010 a las 10:29 +0200, Takashi Iwai escribió:
> > Rejected by SPF lookup: (recv=llar.net.uniovi.es,
> >  send-ip=195.135.220.2) Could not find a valid SPF record
> > User-Agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka)
> FLIM/1.14.9
> >  (=?UTF-8?B?R29qxY0=?=) APEL/10.7 Emacs/23.1 (x86_64-suse-linux-gnu)
> MULE/6.0
> >  (HANACHIRUSATO)
> > References: <1283357723.8159.4.camel at localhost.localdomain>
> >
> > At Wed, 01 Sep 2010 18:15:23 +0200,
> > Pacho Ramos wrote:
> > >
> > > This is an old problem I am suffering since kernel-2.6.32 and that is
> > > still unresolved even with 2.6.35 and alsa-utils-1.0.23:
> > > http://www.spinics.net/lists/alsa-devel/msg31422.html
> > >
> > > If you follow the thread, it got stalled in:
> > > http://www.spinics.net/lists/alsa-devel/msg31433.html
> > >
> > > In summary, I get the following:
> > > # alsactl -f /etc/asound.state restore /dev/snd/controlC0
> > > Unknown hardware: "VIA8237" "Realtek ALC658D" "AC97a:414c4781" "0x147b"
> > > "0x1415"
> > > Hardware is initialized using a guess method
> > > # echo $?
> > > 99
> >
> > This is no error.  It means that alsactl has no special workaround
> > for your hardware.  The return code of alsactl looks strange.
> > I thought Jaroslav has already fixed it, though...
> >
> >
> > Takashi
> >
>
> Well, Jaroslav fixed it to use "99" instead of "157":
> http://www.spinics.net/lists/alsa-devel/msg31430.html
>
> And, about the message, could it be reworded for preventing to make
> users think their hardware is "Unknown"? Maybe it could simply show "No
> workaround needed for: ..." instead of "Unknown hardware"
>
> Thanks :-)
>
>
It seem to me that the current logic of alsactl try to compare  the number
of controls created by the driver and  the number of controls in the state
file before it restore the controls from the state file.

it assume that it cannot restored the setting from the state file when the
number of controls does not match , so it call the init routine instead of
restore routine.

This create a problem for those drivers which have IFACE_PCM "PCM volume
control" since  alsactl does not need to store the value of the controls in
the state file as those per voice volume controls are always initialised
when the stream is open for those sound cards via82xx and ymfpci

This mean that the number of controls in state file is always less than the
number of controls created by the driver and that is the reason why alsactl
always init instead of restore the setting for both  via82xx  and ymfpci

To solve this bug, alsactl should subtract the number of those IFACE_PCM
"PCM volume control" when comparing the number of control in state file