Since kernel-2.6.32 alsactl thinks my sound card is "Unknown"

Since kernel-2.6.32 alsactl thinks my sound card is "Unknown"

[Pacho Ramos]

[-- Attachment #1.1: Type: text/plain, Size: 792 bytes --]

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

As you can see, the exit code was solved, but I don't know why my
hardware is still shown as "Unknown" even if 
via82xx.c clearly has some lines for my device:
        SND_PCI_QUIRK(0x147b, 0x1415, "ABIT AV8", VIA_DXS_NO_VRA),


Thanks a lot for your help

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

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Since kernel-2.6.32 alsactl thinks my sound card is "Unknown"

[Takashi Iwai]

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

> 
> As you can see, the exit code was solved, but I don't know why my
> hardware is still shown as "Unknown" even if 
> via82xx.c clearly has some lines for my device:
>         SND_PCI_QUIRK(0x147b, 0x1415, "ABIT AV8", VIA_DXS_NO_VRA),
> 
> 
> Thanks a lot for your help
> [1.2 This is a digitally signed message part <application/pgp-signature (7bit)>]
> 
> [2  <text/plain; us-ascii (7bit)>]
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Since kernel-2.6.32 alsactl thinks my sound card is "Unknown"

[Pacho Ramos]

[-- Attachment #1.1: Type: text/plain, Size: 1625 bytes --]

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@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 :-)


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

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Since kernel-2.6.32 alsactl thinks my sound card is "Unknown"

[David Henningsson]

2010-09-02 11:26, Pacho Ramos skrev:
> 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@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"

Perhaps "Generic" hardware?

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Since kernel-2.6.32 alsactl thinks my sound card is "Unknown"

[Takashi Iwai]

At Thu, 02 Sep 2010 11:34:51 +0200,
David Henningsson wrote:
> 
> 2010-09-02 11:26, Pacho Ramos skrev:
> > 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@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"
> 
> Perhaps "Generic" hardware?

Sounds reasonable.


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Since kernel-2.6.32 alsactl thinks my sound card is "Unknown"

[Pacho Ramos]

[-- Attachment #1.1: Type: text/plain, Size: 1890 bytes --]

El jue, 02-09-2010 a las 11:34 +0200, David Henningsson escribió:
> 2010-09-02 11:26, Pacho Ramos skrev:
> > 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@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"
> 
> Perhaps "Generic" hardware?
> 

Looks fine for me :-)



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

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Since kernel-2.6.32 alsactl thinks my sound card is "Unknown"

[Jaroslav Kysela]

On Thu, 2 Sep 2010, Pacho Ramos wrote:

>> Perhaps "Generic" hardware?
>>
>
> Looks fine for me :-)

I changed the message to text like:

Found hardware: "HDA-Intel" "Realtek ALC888" "HDA:10ec0888,10438331,00100001" "0x1043" "0x8331"
Hardware is initialized using a generic method

 					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Since kernel-2.6.32 alsactl thinks my sound card is "Unknown"

[Pacho Ramos]

[-- Attachment #1.1: Type: text/plain, Size: 806 bytes --]

El jue, 02-09-2010 a las 15:38 +0200, Jaroslav Kysela escribió:
> On Thu, 2 Sep 2010, Pacho Ramos wrote:
> 
> >> Perhaps "Generic" hardware?
> >>
> >
> > Looks fine for me :-)
> 
> I changed the message to text like:
> 
> Found hardware: "HDA-Intel" "Realtek ALC888" "HDA:10ec0888,10438331,00100001" "0x1043" "0x8331"
> Hardware is initialized using a generic method
> 
>  					Jaroslav
> 
> -----
> Jaroslav Kysela <perex@perex.cz>
> Linux Kernel Sound Maintainer
> ALSA Project, Red Hat, Inc.
> 
> 

I have seen the changes, thanks :-D, but could you also update
alsactl/init/00main information? It's still referring to an "error":
#   5) if RESULT!="true", initialize hardware using a guess method,
#      print an error message and return with exit code 99


Thanks a lot

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

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Since kernel-2.6.32 alsactl thinks my sound card is "Unknown"

[Raymond Yau]

2010/9/2 Pacho Ramos <pacho@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@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

Re: Since kernel-2.6.32 alsactl thinks my sound card is "Unknown"

[Jaroslav Kysela]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4031 bytes --]

On Thu, 2 Sep 2010, Raymond Yau wrote:

> 2010/9/2 Pacho Ramos <pacho@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@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 :-)

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@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Since kernel-2.6.32 alsactl thinks my sound card is "Unknown"

[Raymond Yau]

2010/9/2 Jaroslav Kysela <perex@perex.cz>

> On Thu, 2 Sep 2010, Raymond Yau wrote:
>
>  2010/9/2 Pacho Ramos <pacho@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@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 :-)
>>>
>>
> 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).


Storing those active per voice volume controls in the state file seem to be
used for debugging in the past if hwmixevolume can be used for debugging

an alsa-tool hwmixvolume which allows you to control the volume of
individual streams on sound cards that use hardware mixing, (similar to
pavucontrol or the Sound Preference in Gnome to control the per application
volume of PA clients)

No , you cannot restore those IFACE_PCM controls only when they are active
in the state file , otherwise they don't need to specify lock true in
EMU10K1.conf

                       {
                        interface PCM
                                 name "EMU10K1 PCM Send Volume"
                                 index { @func private_pcm_subdevice }
                                 lock true
                                 optional true
                                 value [ 255 255 0 0 255 0 0 0 0 255 0 0 ]
                         }
                         {
                           interface PCM
                                 name "EMU10K1 PCM Send Routing"
                                 index { @func private_pcm_subdevice }
                                 lock true
                                 optional true
                                 value [ 8 9 0 0 8 9 0 0 8 9 0 0 ]
                         }

This is another case which PA cannot use "front" device for capturing too.

emu10k1 use the setting inf EMU10k1.conf when the application open "front",
"rear" to change the routing

Re: Since kernel-2.6.32 alsactl thinks my sound card is "Unknown"

[Raymond Yau]

2010/9/2 Takashi Iwai <tiwai@suse.de>

> 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
>
> >
> > As you can see, the exit code was solved, but I don't know why my
> > hardware is still shown as "Unknown" even if
> > via82xx.c clearly has some lines for my device:
> >         SND_PCI_QUIRK(0x147b, 0x1415, "ABIT AV8", VIA_DXS_NO_VRA),
> >
> >
>


why "alsactl init" does not select "Mic" as "Capture Source" for AC97 codec
?

it seem "alsactl init" does not set "Mic Boost" too

Re: Since kernel-2.6.32 alsactl thinks my sound card is "Unknown"

[Jaroslav Kysela]

On Tue, 7 Sep 2010, Raymond Yau wrote:

> 2010/9/2 Takashi Iwai <tiwai@suse.de>
>
>> 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
>>
>>>
>>> As you can see, the exit code was solved, but I don't know why my
>>> hardware is still shown as "Unknown" even if
>>> via82xx.c clearly has some lines for my device:
>>>         SND_PCI_QUIRK(0x147b, 0x1415, "ABIT AV8", VIA_DXS_NO_VRA),
>>>
>>>
>>
>
>
> why "alsactl init" does not select "Mic" as "Capture Source" for AC97 codec
> ?
>
> it seem "alsactl init" does not set "Mic Boost" too

This patch should change the initial script to set these two controls:

http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=52bd2f8acedaacce32ca8e89cb1f21683658648e

 					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.