On Thu, 2 Sep 2010, Raymond Yau wrote:
2010/9/2 Pacho Ramos <pacho@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxx>
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 :-)
I renamed string to "Found hardware:" to avoid this confusion.
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
But this policy is not universal. Basically, the problem is for two types
of controls:
1) static, created in the driver, which can go to the inactive state
2) dynamic ones
The first type can be solved by storing of inactive values to the state
file. The restore procedure will know about all static driver controls and
can just skip ones which are marked inactive in the state file or in the
driver (it means that the controls which can be inactive will be restored
only when they are active in the state file and in the driver). Another
possibility is to mark these controls with a temporary flag to skip them
inside alsactl.
The second one (dynamic controls) are more difficult to handle. We cannot
distinguish them from static controls now.
It seems that the best method will be to restore what we can and
initialize rest without overwritting the restored controls (something like
"merge" mode - restore+init).
Jaroslav
-----
Jaroslav Kysela <perex@xxxxxxxx>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
