alsactl restore: unknown hardware: ymf724f

alsactl restore: unknown hardware: ymf724f

[Angel Tsankov]

Hello,

I run 'alsactl restore' on a machine with 2 sound cards -- a built-in 
Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 
02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio 
Controller] (rev 03) -- and get the following message:

Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84" "AC97a:83847600"
"0x1073" "0x000d"
Hardware is initialized using a guess method

As a consequence the volume levels of the Yamaha card do not get 
restored to the levels stored in /etc/asound.state.  The volume levels 
of the built-in card however are properly restored.  The asound.state 
file has been created by executing 'alsactl store'.

The kernel has been built with support for ALSA.  I've built and
installed the kernel modules for both cards (not the ones in the 
alsa-driver package but those that come with kernel version 2.6.30.2). 
Any ideas why alsactl cannot find the hardware it has previously 
identified as "YMF724F", "SigmaTel STAC9700,83,84", and so on?

Regards,
Angel Tsankov

Re: alsactl restore: unknown hardware: ymf724f

[Jaroslav Kysela]

On Thu, 25 Feb 2010, Angel Tsankov wrote:

> Hello,
>
> I run 'alsactl restore' on a machine with 2 sound cards -- a built-in
> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev
> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
> Controller] (rev 03) -- and get the following message:
>
> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84" "AC97a:83847600"
> "0x1073" "0x000d"
> Hardware is initialized using a guess method
>
> As a consequence the volume levels of the Yamaha card do not get
> restored to the levels stored in /etc/asound.state.  The volume levels
> of the built-in card however are properly restored.  The asound.state
> file has been created by executing 'alsactl store'.
>
> The kernel has been built with support for ALSA.  I've built and
> installed the kernel modules for both cards (not the ones in the
> alsa-driver package but those that come with kernel version 2.6.30.2).
> Any ideas why alsactl cannot find the hardware it has previously
> identified as "YMF724F", "SigmaTel STAC9700,83,84", and so on?

The logic of alsactl is to restore the state from /etc/asound.state if it 
is valid. It seems like the set_controls() function in alsactl/state.c 
returns an error code for a reason.

Could you try to compile the latest alsa-utils snapshot 
(http://www.alsa-project.org/snapshot/) and run './alsactl -d restore' in 
alsa-utils/alsactl directory? A warning (fail reason) should be printed.

 					Jaroslav

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

Re: alsactl restore: unknown hardware: ymf724f

[Angel Tsankov]

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

Jaroslav Kysela wrote:
> On Thu, 25 Feb 2010, Angel Tsankov wrote:
> 
>> Hello,
>>
>> I run 'alsactl restore' on a machine with 2 sound cards -- a built-in
>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev
>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
>> Controller] (rev 03) -- and get the following message:
>>
>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84" "AC97a:83847600"
>> "0x1073" "0x000d"
>> Hardware is initialized using a guess method
>>
>> As a consequence the volume levels of the Yamaha card do not get
>> restored to the levels stored in /etc/asound.state.  The volume levels
>> of the built-in card however are properly restored.  The asound.state
>> file has been created by executing 'alsactl store'.
>>
>> The kernel has been built with support for ALSA.  I've built and
>> installed the kernel modules for both cards (not the ones in the
>> alsa-driver package but those that come with kernel version 2.6.30.2).
>> Any ideas why alsactl cannot find the hardware it has previously
>> identified as "YMF724F", "SigmaTel STAC9700,83,84", and so on?
> 
> The logic of alsactl is to restore the state from /etc/asound.state if it 
> is valid. It seems like the set_controls() function in alsactl/state.c 
> returns an error code for a reason.
> 
> Could you try to compile the latest alsa-utils snapshot 
> (http://www.alsa-project.org/snapshot/) and run './alsactl -d restore' in 
> alsa-utils/alsactl directory? A warning (fail reason) should be printed.
> 
>  					Jaroslav

I've attached a bash shell script that I used to download, configure, 
compile, and run alsactl.  I've also attached a .log file with stdout 
and stderr that I got while executing the script.


Regards,
Angel Tsankov

[-- Attachment #2: test-alsa-utils.log.tar.bz2 --]
[-- Type: application/octet-stream, Size: 7348 bytes --]

[-- Attachment #3: test-alsa-utils.tar.bz2 --]
[-- Type: application/octet-stream, Size: 382 bytes --]

[-- Attachment #4: 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: alsactl restore: unknown hardware: ymf724f

[Jaroslav Kysela]

On Thu, 25 Feb 2010, Angel Tsankov wrote:

> Jaroslav Kysela wrote:
>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
>> 
>>> Hello,
>>> 
>>> I run 'alsactl restore' on a machine with 2 sound cards -- a built-in
>>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev
>>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
>>> Controller] (rev 03) -- and get the following message:
>>> 
>>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84" "AC97a:83847600"
>>> "0x1073" "0x000d"
>>> Hardware is initialized using a guess method
>>> 
>>> As a consequence the volume levels of the Yamaha card do not get
>>> restored to the levels stored in /etc/asound.state.  The volume levels
>>> of the built-in card however are properly restored.  The asound.state
>>> file has been created by executing 'alsactl store'.
>>> 
>>> The kernel has been built with support for ALSA.  I've built and
>>> installed the kernel modules for both cards (not the ones in the
>>> alsa-driver package but those that come with kernel version 2.6.30.2).
>>> Any ideas why alsactl cannot find the hardware it has previously
>>> identified as "YMF724F", "SigmaTel STAC9700,83,84", and so on?
>> 
>> The logic of alsactl is to restore the state from /etc/asound.state if it 
>> is valid. It seems like the set_controls() function in alsactl/state.c 
>> returns an error code for a reason.
>> 
>> Could you try to compile the latest alsa-utils snapshot 
>> (http://www.alsa-project.org/snapshot/) and run './alsactl -d restore' in 
>> alsa-utils/alsactl directory? A warning (fail reason) should be printed.
>
> I've attached a bash shell script that I used to download, configure, 
> compile, and run alsactl.  I've also attached a .log file with stdout and 
> stderr that I got while executing the script.

Thanks. I've added more debug print lines to state.c. Could you rerun your 
script and append also '/etc/asound.state' file and output from 
'alsa-info.sh --no-upload' to your output tarballs? Send me this tarball
privately or just an URL to this list.

 					Thanks,
 						Jaroslav

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

Re: alsactl restore: unknown hardware: ymf724f

[Raymond Yau]

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

> On Thu, 25 Feb 2010, Angel Tsankov wrote:
>
> > Jaroslav Kysela wrote:
> >> On Thu, 25 Feb 2010, Angel Tsankov wrote:
> >>
> >>> Hello,
> >>>
> >>> I run 'alsactl restore' on a machine with 2 sound cards -- a built-in
> >>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev
> >>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
> >>> Controller] (rev 03) -- and get the following message:
> >>>
> >>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84" "AC97a:83847600"
> >>> "0x1073" "0x000d"
> >>> Hardware is initialized using a guess method
> >>>
> >>> As a consequence the volume levels of the Yamaha card do not get
> >>> restored to the levels stored in /etc/asound.state.  The volume levels
> >>> of the built-in card however are properly restored.  The asound.state
> >>> file has been created by executing 'alsactl store'.
> >>>
> >>> The kernel has been built with support for ALSA.  I've built and
> >>> installed the kernel modules for both cards (not the ones in the
> >>> alsa-driver package but those that come with kernel version 2.6.30.2).
> >>> Any ideas why alsactl cannot find the hardware it has previously
> >>> identified as "YMF724F", "SigmaTel STAC9700,83,84", and so on?
> >>
> >> The logic of alsactl is to restore the state from /etc/asound.state if
> it
> >> is valid. It seems like the set_controls() function in alsactl/state.c
> >> returns an error code for a reason.
> >>
> >> Could you try to compile the latest alsa-utils snapshot
> >> (http://www.alsa-project.org/snapshot/) and run './alsactl -d restore'
> in
> >> alsa-utils/alsactl directory? A warning (fail reason) should be printed.
> >
> > I've attached a bash shell script that I used to download, configure,
> > compile, and run alsactl.  I've also attached a .log file with stdout and
> > stderr that I got while executing the script.
>
> Thanks. I've added more debug print lines to state.c. Could you rerun your
> script and append also '/etc/asound.state' file and output from
> 'alsa-info.sh --no-upload' to your output tarballs? Send me this tarball
> privately or just an URL to this list.
>
>                                        Thanks,
>                                                 Jaroslav
>
>
did alsactl restore those IFACE_PCM volume since they are supposed at 0dB by
default whenever the subdevice is open ?

store the values in asound.state seem to be for debugging only

    control.61 {
        comment.access 'read write inactive'
        comment.type INTEGER
        comment.count 2
        comment.range '0 - 32768'
        iface PCM
        subdevice 1
        name 'PCM Playback Volume'
        value.0 26214
        value.1 26214
    }

Re: alsactl restore: unknown hardware: ymf724f

[Angel Tsankov]

Raymond Yau wrote:
> 2010/2/25 Jaroslav Kysela <perex@perex.cz>
> 
>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>
>>> Jaroslav Kysela wrote:
>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I run 'alsactl restore' on a machine with 2 sound cards -- a built-in
>>>>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev
>>>>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
>>>>> Controller] (rev 03) -- and get the following message:
>>>>>
>>>>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84" "AC97a:83847600"
>>>>> "0x1073" "0x000d"
>>>>> Hardware is initialized using a guess method
>>>>>
>>>>> As a consequence the volume levels of the Yamaha card do not get
>>>>> restored to the levels stored in /etc/asound.state.  The volume levels
>>>>> of the built-in card however are properly restored.  The asound.state
>>>>> file has been created by executing 'alsactl store'.
>>>>>
>>>>> The kernel has been built with support for ALSA.  I've built and
>>>>> installed the kernel modules for both cards (not the ones in the
>>>>> alsa-driver package but those that come with kernel version 2.6.30.2).
>>>>> Any ideas why alsactl cannot find the hardware it has previously
>>>>> identified as "YMF724F", "SigmaTel STAC9700,83,84", and so on?
>>>> The logic of alsactl is to restore the state from /etc/asound.state if
>> it
>>>> is valid. It seems like the set_controls() function in alsactl/state.c
>>>> returns an error code for a reason.
>>>>
>>>> Could you try to compile the latest alsa-utils snapshot
>>>> (http://www.alsa-project.org/snapshot/) and run './alsactl -d restore'
>> in
>>>> alsa-utils/alsactl directory? A warning (fail reason) should be printed.
>>> I've attached a bash shell script that I used to download, configure,
>>> compile, and run alsactl.  I've also attached a .log file with stdout and
>>> stderr that I got while executing the script.
>> Thanks. I've added more debug print lines to state.c. Could you rerun your
>> script and append also '/etc/asound.state' file and output from
>> 'alsa-info.sh --no-upload' to your output tarballs? Send me this tarball
>> privately or just an URL to this list.
>>
>>                                        Thanks,
>>                                                 Jaroslav
>>
>>
> did alsactl restore those IFACE_PCM volume since they are supposed at 0dB by
> default whenever the subdevice is open ?
> 
> store the values in asound.state seem to be for debugging only
> 
>     control.61 {
>         comment.access 'read write inactive'
>         comment.type INTEGER
>         comment.count 2
>         comment.range '0 - 32768'
>         iface PCM
>         subdevice 1
>         name 'PCM Playback Volume'
>         value.0 26214
>         value.1 26214
>     }

In fact, alsactl seems to restore the volume levels (despite the 
"Unknown hardware" message) when the system is up and running, but it 
does not restore the PCM and master levels at boot time. This should be 
done when the hardware is detected by udev, as I have the following udev 
rule:

KERNEL=="controlC[0-9]*", ACTION=="add", RUN+="/usr/sbin/alsactl restore %n"


Angel Tsankov

Re: alsactl restore: unknown hardware: ymf724f

[Pacho Ramos]

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

El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió:
> Raymond Yau wrote:
> > 2010/2/25 Jaroslav Kysela <perex@perex.cz>
> > 
> >> On Thu, 25 Feb 2010, Angel Tsankov wrote:
> >>
> >>> Jaroslav Kysela wrote:
> >>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> I run 'alsactl restore' on a machine with 2 sound cards -- a built-in
> >>>>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev
> >>>>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
> >>>>> Controller] (rev 03) -- and get the following message:
> >>>>>
> >>>>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84" "AC97a:83847600"
> >>>>> "0x1073" "0x000d"
> >>>>> Hardware is initialized using a guess method
> >>>>>
> >>>>> As a consequence the volume levels of the Yamaha card do not get
> >>>>> restored to the levels stored in /etc/asound.state.  The volume levels
> >>>>> of the built-in card however are properly restored.  The asound.state
> >>>>> file has been created by executing 'alsactl store'.
> >>>>>
> >>>>> The kernel has been built with support for ALSA.  I've built and
> >>>>> installed the kernel modules for both cards (not the ones in the
> >>>>> alsa-driver package but those that come with kernel version 2.6.30.2).
> >>>>> Any ideas why alsactl cannot find the hardware it has previously
> >>>>> identified as "YMF724F", "SigmaTel STAC9700,83,84", and so on?
> >>>> The logic of alsactl is to restore the state from /etc/asound.state if
> >> it
> >>>> is valid. It seems like the set_controls() function in alsactl/state.c
> >>>> returns an error code for a reason.
> >>>>
> >>>> Could you try to compile the latest alsa-utils snapshot
> >>>> (http://www.alsa-project.org/snapshot/) and run './alsactl -d restore'
> >> in
> >>>> alsa-utils/alsactl directory? A warning (fail reason) should be printed.
> >>> I've attached a bash shell script that I used to download, configure,
> >>> compile, and run alsactl.  I've also attached a .log file with stdout and
> >>> stderr that I got while executing the script.
> >> Thanks. I've added more debug print lines to state.c. Could you rerun your
> >> script and append also '/etc/asound.state' file and output from
> >> 'alsa-info.sh --no-upload' to your output tarballs? Send me this tarball
> >> privately or just an URL to this list.


Looks similar to my problem:
http://www.spinics.net/lists/alsa-devel/msg31422.html


[-- Attachment #1.2: Esta parte del mensaje está firmada digitalmente --]
[-- 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: alsactl restore: unknown hardware: ymf724f

[Angel Tsankov]

Pacho Ramos wrote:
> El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió:
>> Raymond Yau wrote:
>>> 2010/2/25 Jaroslav Kysela <perex@perex.cz>
>>>
>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>
>>>>> Jaroslav Kysela wrote:
>>>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I run 'alsactl restore' on a machine with 2 sound cards -- a built-in
>>>>>>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev
>>>>>>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
>>>>>>> Controller] (rev 03) -- and get the following message:
>>>>>>>
>>>>>>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84" "AC97a:83847600"
>>>>>>> "0x1073" "0x000d"
>>>>>>> Hardware is initialized using a guess method
>>>>>>>
>>>>>>> As a consequence the volume levels of the Yamaha card do not get
>>>>>>> restored to the levels stored in /etc/asound.state.  The volume levels
>>>>>>> of the built-in card however are properly restored.  The asound.state
>>>>>>> file has been created by executing 'alsactl store'.
>>>>>>>
>>>>>>> The kernel has been built with support for ALSA.  I've built and
>>>>>>> installed the kernel modules for both cards (not the ones in the
>>>>>>> alsa-driver package but those that come with kernel version 2.6.30.2).
>>>>>>> Any ideas why alsactl cannot find the hardware it has previously
>>>>>>> identified as "YMF724F", "SigmaTel STAC9700,83,84", and so on?
>>>>>> The logic of alsactl is to restore the state from /etc/asound.state if
>>>> it
>>>>>> is valid. It seems like the set_controls() function in alsactl/state.c
>>>>>> returns an error code for a reason.
>>>>>>
>>>>>> Could you try to compile the latest alsa-utils snapshot
>>>>>> (http://www.alsa-project.org/snapshot/) and run './alsactl -d restore'
>>>> in
>>>>>> alsa-utils/alsactl directory? A warning (fail reason) should be printed.
>>>>> I've attached a bash shell script that I used to download, configure,
>>>>> compile, and run alsactl.  I've also attached a .log file with stdout and
>>>>> stderr that I got while executing the script.
>>>> Thanks. I've added more debug print lines to state.c. Could you rerun your
>>>> script and append also '/etc/asound.state' file and output from
>>>> 'alsa-info.sh --no-upload' to your output tarballs? Send me this tarball
>>>> privately or just an URL to this list.
> 
> 
> Looks similar to my problem:
> http://www.spinics.net/lists/alsa-devel/msg31422.html

Most interestingly, my exit status is the same -- 157.  I thought it was 99.


Regards,
Angel Tsankov

Re: alsactl restore: unknown hardware: ymf724f

[Raymond Yau]

2010/2/26 Angel Tsankov <fn42551@fmi.uni-sofia.bg>

> Raymond Yau wrote:
> > 2010/2/25 Jaroslav Kysela <perex@perex.cz>
> >
> >> On Thu, 25 Feb 2010, Angel Tsankov wrote:
> >>
> >>> Jaroslav Kysela wrote:
> >>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> I run 'alsactl restore' on a machine with 2 sound cards -- a built-in
> >>>>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev
> >>>>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
> >>>>> Controller] (rev 03) -- and get the following message:
> >>>>>
> >>>>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84"
> "AC97a:83847600"
> >>>>> "0x1073" "0x000d"
> >>>>> Hardware is initialized using a guess method
> >>>>>
> >>>>> As a consequence the volume levels of the Yamaha card do not get
> >>>>> restored to the levels stored in /etc/asound.state.  The volume
> levels
> >>>>> of the built-in card however are properly restored.  The asound.state
> >>>>> file has been created by executing 'alsactl store'.
> >>>>>
> >>>>> The kernel has been built with support for ALSA.  I've built and
> >>>>> installed the kernel modules for both cards (not the ones in the
> >>>>> alsa-driver package but those that come with kernel version
> 2.6.30.2).
> >>>>> Any ideas why alsactl cannot find the hardware it has previously
> >>>>> identified as "YMF724F", "SigmaTel STAC9700,83,84", and so on?
> >>>> The logic of alsactl is to restore the state from /etc/asound.state if
> >> it
> >>>> is valid. It seems like the set_controls() function in alsactl/state.c
> >>>> returns an error code for a reason.
> >>>>
> >>>> Could you try to compile the latest alsa-utils snapshot
> >>>> (http://www.alsa-project.org/snapshot/) and run './alsactl -d
> restore'
> >> in
> >>>> alsa-utils/alsactl directory? A warning (fail reason) should be
> printed.
> >>> I've attached a bash shell script that I used to download, configure,
> >>> compile, and run alsactl.  I've also attached a .log file with stdout
> and
> >>> stderr that I got while executing the script.
> >> Thanks. I've added more debug print lines to state.c. Could you rerun
> your
> >> script and append also '/etc/asound.state' file and output from
> >> 'alsa-info.sh --no-upload' to your output tarballs? Send me this tarball
> >> privately or just an URL to this list.
> >>
> >>                                        Thanks,
> >>                                                 Jaroslav
> >>
> >>
> > did alsactl restore those IFACE_PCM volume since they are supposed at 0dB
> by
> > default whenever the subdevice is open ?
> >
> > store the values in asound.state seem to be for debugging only
> >
> >     control.61 {
> >         comment.access 'read write inactive'
> >         comment.type INTEGER
> >         comment.count 2
> >         comment.range '0 - 32768'
> >         iface PCM
> >         subdevice 1
> >         name 'PCM Playback Volume'
> >         value.0 26214
> >         value.1 26214
> >     }
>
> In fact, alsactl seems to restore the volume levels (despite the
> "Unknown hardware" message) when the system is up and running, but it
> does not restore the PCM and master levels at boot time. This should be
> done when the hardware is detected by udev, as I have the following udev
> rule:
>
> KERNEL=="controlC[0-9]*", ACTION=="add", RUN+="/usr/sbin/alsactl restore
> %n"
>
>
> Angel Tsankov
>
>
Can you store the iface PCM "PCM Playback Volume" in asound.state while you
are playing audio ?

alsactl can store the value since the control is active when the subdevice
is open

alsactl already skip restoring of those control when it is not active , so
the problem seem not related to those controls

However via82xx also have those hardware specific controls

Re: alsactl restore: unknown hardware: ymf724f

[Raymond Yau]

2010/2/26 Pacho Ramos <pacho@condmat1.ciencias.uniovi.es>

> El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió:
> > Raymond Yau wrote:
> > > 2010/2/25 Jaroslav Kysela <perex@perex.cz>
> > >
> > >> On Thu, 25 Feb 2010, Angel Tsankov wrote:
> > >>
> > >>> Jaroslav Kysela wrote:
> > >>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
> > >>>>
> > >>>>> Hello,
> > >>>>>
> > >>>>> I run 'alsactl restore' on a machine with 2 sound cards -- a
> built-in
> > >>>>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller
> (rev
> > >>>>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
> > >>>>> Controller] (rev 03) -- and get the following message:
> > >>>>>
> > >>>>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84"
> "AC97a:83847600"
> > >>>>> "0x1073" "0x000d"
> > >>>>> Hardware is initialized using a guess method
> > >>>>>
> > >>>>> As a consequence the volume levels of the Yamaha card do not get
> > >>>>> restored to the levels stored in /etc/asound.state.  The volume
> levels
> > >>>>> of the built-in card however are properly restored.  The
> asound.state
> > >>>>> file has been created by executing 'alsactl store'.
> > >>>>>
> > >>>>> The kernel has been built with support for ALSA.  I've built and
> > >>>>> installed the kernel modules for both cards (not the ones in the
> > >>>>> alsa-driver package but those that come with kernel version
> 2.6.30.2).
> > >>>>> Any ideas why alsactl cannot find the hardware it has previously
> > >>>>> identified as "YMF724F", "SigmaTel STAC9700,83,84", and so on?
> > >>>> The logic of alsactl is to restore the state from /etc/asound.state
> if
> > >> it
> > >>>> is valid. It seems like the set_controls() function in
> alsactl/state.c
> > >>>> returns an error code for a reason.
> > >>>>
> > >>>> Could you try to compile the latest alsa-utils snapshot
> > >>>> (http://www.alsa-project.org/snapshot/) and run './alsactl -d
> restore'
> > >> in
> > >>>> alsa-utils/alsactl directory? A warning (fail reason) should be
> printed.
> > >>> I've attached a bash shell script that I used to download, configure,
> > >>> compile, and run alsactl.  I've also attached a .log file with stdout
> and
> > >>> stderr that I got while executing the script.
> > >> Thanks. I've added more debug print lines to state.c. Could you rerun
> your
> > >> script and append also '/etc/asound.state' file and output from
> > >> 'alsa-info.sh --no-upload' to your output tarballs? Send me this
> tarball
> > >> privately or just an URL to this list.
>
>
> Looks similar to my problem:
> http://www.spinics.net/lists/alsa-devel/msg31422.html
>
>
>
what is the content of your asound.state ?

seem related to this patch if alsactl count those iface_pcm controls

when driver contains more controls than state file. In this case,
initialization procedure should be run

http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=05f78cc6811110156c701fd9a2a5d15de8b4b1c7;hp=6232f1c96cde1fee247e95cd97235c48cc7b168d

Re: alsactl restore: unknown hardware: ymf724f

[Angel Tsankov]

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

Raymond Yau wrote:
> 2010/2/26 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
> 
>> Raymond Yau wrote:
>>> 2010/2/25 Jaroslav Kysela <perex@perex.cz>
>>>
>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>
>>>>> Jaroslav Kysela wrote:
>>>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I run 'alsactl restore' on a machine with 2 sound cards -- a built-in
>>>>>>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev
>>>>>>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
>>>>>>> Controller] (rev 03) -- and get the following message:
>>>>>>>
>>>>>>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84"
>> "AC97a:83847600"
>>>>>>> "0x1073" "0x000d"
>>>>>>> Hardware is initialized using a guess method
>>>>>>>
>>>>>>> As a consequence the volume levels of the Yamaha card do not get
>>>>>>> restored to the levels stored in /etc/asound.state.  The volume
>> levels
>>>>>>> of the built-in card however are properly restored.  The asound.state
>>>>>>> file has been created by executing 'alsactl store'.
>>>>>>>
>>>>>>> The kernel has been built with support for ALSA.  I've built and
>>>>>>> installed the kernel modules for both cards (not the ones in the
>>>>>>> alsa-driver package but those that come with kernel version
>> 2.6.30.2).
>>>>>>> Any ideas why alsactl cannot find the hardware it has previously
>>>>>>> identified as "YMF724F", "SigmaTel STAC9700,83,84", and so on?
>>>>>> The logic of alsactl is to restore the state from /etc/asound.state if
>>>> it
>>>>>> is valid. It seems like the set_controls() function in alsactl/state.c
>>>>>> returns an error code for a reason.
>>>>>>
>>>>>> Could you try to compile the latest alsa-utils snapshot
>>>>>> (http://www.alsa-project.org/snapshot/) and run './alsactl -d
>> restore'
>>>> in
>>>>>> alsa-utils/alsactl directory? A warning (fail reason) should be
>> printed.
>>>>> I've attached a bash shell script that I used to download, configure,
>>>>> compile, and run alsactl.  I've also attached a .log file with stdout
>> and
>>>>> stderr that I got while executing the script.
>>>> Thanks. I've added more debug print lines to state.c. Could you rerun
>> your
>>>> script and append also '/etc/asound.state' file and output from
>>>> 'alsa-info.sh --no-upload' to your output tarballs? Send me this tarball
>>>> privately or just an URL to this list.
>>>>
>>>>                                        Thanks,
>>>>                                                 Jaroslav
>>>>
>>>>
>>> did alsactl restore those IFACE_PCM volume since they are supposed at 0dB
>> by
>>> default whenever the subdevice is open ?
>>>
>>> store the values in asound.state seem to be for debugging only
>>>
>>>     control.61 {
>>>         comment.access 'read write inactive'
>>>         comment.type INTEGER
>>>         comment.count 2
>>>         comment.range '0 - 32768'
>>>         iface PCM
>>>         subdevice 1
>>>         name 'PCM Playback Volume'
>>>         value.0 26214
>>>         value.1 26214
>>>     }
>> In fact, alsactl seems to restore the volume levels (despite the
>> "Unknown hardware" message) when the system is up and running, but it
>> does not restore the PCM and master levels at boot time. This should be
>> done when the hardware is detected by udev, as I have the following udev
>> rule:
>>
>> KERNEL=="controlC[0-9]*", ACTION=="add", RUN+="/usr/sbin/alsactl restore
>> %n"
>>
>>
>> Angel Tsankov
>>
>>
> Can you store the iface PCM "PCM Playback Volume" in asound.state while you
> are playing audio ?
> 
> alsactl can store the value since the control is active when the subdevice
> is open
> 
> alsactl already skip restoring of those control when it is not active , so
> the problem seem not related to those controls
> 
> However via82xx also have those hardware specific controls

It seems that when I store the values while the sound card is playing I 
get one more control in asound.state (see attached archive).

Here's the test I did:

1. I removed /etc/asound.state (just in case);
2. I made sure the sound card is not playing, ran 'alsactl store', and 
renamed /etc/asound.state to /etc/asound.state.not-playing;
3. I started vlc, played some music, ran 'alsactl store' once again, and 
renamed /etc/asound.state to /etc/asound.state.playing;

Then I diff'ed the two files and found out that they are different. I'm 
sending them as alsactl created them.


Regards,
Angel Tsankov

[-- Attachment #2: asound.state.tar.bz2 --]
[-- Type: application/octet-stream, Size: 1696 bytes --]

[-- Attachment #3: 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: alsactl restore: unknown hardware: ymf724f

[Raymond Yau]

2010/2/27 Angel Tsankov <fn42551@fmi.uni-sofia.bg>

> Raymond Yau wrote:
>
>> 2010/2/26 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
>>
>>  Raymond Yau wrote:
>>>
>>>> 2010/2/25 Jaroslav Kysela <perex@perex.cz>
>>>>
>>>>  On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>>
>>>>>  Jaroslav Kysela wrote:
>>>>>>
>>>>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>>>>
>>>>>>>  Hello,
>>>>>>>>
>>>>>>>> I run 'alsactl restore' on a machine with 2 sound cards -- a
>>>>>>>> built-in
>>>>>>>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller
>>>>>>>> (rev
>>>>>>>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
>>>>>>>> Controller] (rev 03) -- and get the following message:
>>>>>>>>
>>>>>>>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84"
>>>>>>>>
>>>>>>> "AC97a:83847600"
>>>
>>>> "0x1073" "0x000d"
>>>>>>>> Hardware is initialized using a guess method
>>>>>>>>
>>>>>>>> As a consequence the volume levels of the Yamaha card do not get
>>>>>>>> restored to the levels stored in /etc/asound.state.  The volume
>>>>>>>>
>>>>>>> levels
>>>
>>>> of the built-in card however are properly restored.  The asound.state
>>>>>>>> file has been created by executing 'alsactl store'.
>>>>>>>>
>>>>>>>> The kernel has been built with support for ALSA.  I've built and
>>>>>>>> installed the kernel modules for both cards (not the ones in the
>>>>>>>> alsa-driver package but those that come with kernel version
>>>>>>>>
>>>>>>> 2.6.30.2).
>>>
>>>> Any ideas why alsactl cannot find the hardware it has previously
>>>>>>>> identified as "YMF724F", "SigmaTel STAC9700,83,84", and so on?
>>>>>>>>
>>>>>>> The logic of alsactl is to restore the state from /etc/asound.state
>>>>>>> if
>>>>>>>
>>>>>> it
>>>>>
>>>>>> is valid. It seems like the set_controls() function in alsactl/state.c
>>>>>>> returns an error code for a reason.
>>>>>>>
>>>>>>> Could you try to compile the latest alsa-utils snapshot
>>>>>>> (http://www.alsa-project.org/snapshot/) and run './alsactl -d
>>>>>>>
>>>>>> restore'
>>>
>>>> in
>>>>>
>>>>>> alsa-utils/alsactl directory? A warning (fail reason) should be
>>>>>>>
>>>>>> printed.
>>>
>>>> I've attached a bash shell script that I used to download, configure,
>>>>>> compile, and run alsactl.  I've also attached a .log file with stdout
>>>>>>
>>>>> and
>>>
>>>> stderr that I got while executing the script.
>>>>>>
>>>>> Thanks. I've added more debug print lines to state.c. Could you rerun
>>>>>
>>>> your
>>>
>>>> script and append also '/etc/asound.state' file and output from
>>>>> 'alsa-info.sh --no-upload' to your output tarballs? Send me this
>>>>> tarball
>>>>> privately or just an URL to this list.
>>>>>
>>>>>                                       Thanks,
>>>>>                                                Jaroslav
>>>>>
>>>>>
>>>>>  did alsactl restore those IFACE_PCM volume since they are supposed at
>>>> 0dB
>>>>
>>> by
>>>
>>>> default whenever the subdevice is open ?
>>>>
>>>> store the values in asound.state seem to be for debugging only
>>>>
>>>>    control.61 {
>>>>        comment.access 'read write inactive'
>>>>        comment.type INTEGER
>>>>        comment.count 2
>>>>        comment.range '0 - 32768'
>>>>        iface PCM
>>>>        subdevice 1
>>>>        name 'PCM Playback Volume'
>>>>        value.0 26214
>>>>        value.1 26214
>>>>    }
>>>>
>>> In fact, alsactl seems to restore the volume levels (despite the
>>> "Unknown hardware" message) when the system is up and running, but it
>>> does not restore the PCM and master levels at boot time. This should be
>>> done when the hardware is detected by udev, as I have the following udev
>>> rule:
>>>
>>> KERNEL=="controlC[0-9]*", ACTION=="add", RUN+="/usr/sbin/alsactl restore
>>> %n"
>>>
>>>
>>> Angel Tsankov
>>>
>>>
>>>  Can you store the iface PCM "PCM Playback Volume" in asound.state while
>> you
>> are playing audio ?
>>
>> alsactl can store the value since the control is active when the subdevice
>> is open
>>
>> alsactl already skip restoring of those control when it is not active , so
>> the problem seem not related to those controls
>>
>> However via82xx also have those hardware specific controls
>>
>
> It seems that when I store the values while the sound card is playing I get
> one more control in asound.state (see attached archive).
>
> Here's the test I did:
>
> 1. I removed /etc/asound.state (just in case);
> 2. I made sure the sound card is not playing, ran 'alsactl store', and
> renamed /etc/asound.state to /etc/asound.state.not-playing;
> 3. I started vlc, played some music, ran 'alsactl store' once again, and
> renamed /etc/asound.state to /etc/asound.state.playing;
>
> Then I diff'ed the two files and found out that they are different. I'm
> sending them as alsactl created them.
>
>
> Regards,
> Angel Tsankov
>


This is the extra control saved when you are playing audio on subdevice 0


    control.48 {
        comment.access 'read write'
        comment.type INTEGER
        comment.count 2
        comment.range '0 - 32768'
        iface PCM
        name 'PCM Playback Volume'
        value.0 32768
        value.1 32768
    }

This look like there is any sound (login/system boot event sound)  playing
when you perform alsactl restore , the driver will contain more control than
state file , it will not restore but perform initialization


when driver contains more controls than state file. In this case,
initialization procedure should be run

http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=05f78cc6811110156c701fd9a2a5d15de8b4b1c7;hp=6232f1c96cde1fee247e95cd97235c48cc7b168d

Re: alsactl restore: unknown hardware: ymf724f

[Angel Tsankov]

Raymond Yau wrote:
> 2010/2/27 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
> 
>> Raymond Yau wrote:
>>
>>> 2010/2/26 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
>>>
>>>  Raymond Yau wrote:
>>>>> 2010/2/25 Jaroslav Kysela <perex@perex.cz>
>>>>>
>>>>>  On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>>>  Jaroslav Kysela wrote:
>>>>>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>>>>>
>>>>>>>>  Hello,
>>>>>>>>> I run 'alsactl restore' on a machine with 2 sound cards -- a
>>>>>>>>> built-in
>>>>>>>>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller
>>>>>>>>> (rev
>>>>>>>>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
>>>>>>>>> Controller] (rev 03) -- and get the following message:
>>>>>>>>>
>>>>>>>>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84"
>>>>>>>>>
>>>>>>>> "AC97a:83847600"
>>>>> "0x1073" "0x000d"
>>>>>>>>> Hardware is initialized using a guess method
>>>>>>>>>
>>>>>>>>> As a consequence the volume levels of the Yamaha card do not get
>>>>>>>>> restored to the levels stored in /etc/asound.state.  The volume
>>>>>>>>>
>>>>>>>> levels
>>>>> of the built-in card however are properly restored.  The asound.state
>>>>>>>>> file has been created by executing 'alsactl store'.
>>>>>>>>>
>>>>>>>>> The kernel has been built with support for ALSA.  I've built and
>>>>>>>>> installed the kernel modules for both cards (not the ones in the
>>>>>>>>> alsa-driver package but those that come with kernel version
>>>>>>>>>
>>>>>>>> 2.6.30.2).
>>>>> Any ideas why alsactl cannot find the hardware it has previously
>>>>>>>>> identified as "YMF724F", "SigmaTel STAC9700,83,84", and so on?
>>>>>>>>>
>>>>>>>> The logic of alsactl is to restore the state from /etc/asound.state
>>>>>>>> if
>>>>>>>>
>>>>>>> it
>>>>>>> is valid. It seems like the set_controls() function in alsactl/state.c
>>>>>>>> returns an error code for a reason.
>>>>>>>>
>>>>>>>> Could you try to compile the latest alsa-utils snapshot
>>>>>>>> (http://www.alsa-project.org/snapshot/) and run './alsactl -d
>>>>>>>>
>>>>>>> restore'
>>>>> in
>>>>>>> alsa-utils/alsactl directory? A warning (fail reason) should be
>>>>>>> printed.
>>>>> I've attached a bash shell script that I used to download, configure,
>>>>>>> compile, and run alsactl.  I've also attached a .log file with stdout
>>>>>>>
>>>>>> and
>>>>> stderr that I got while executing the script.
>>>>>> Thanks. I've added more debug print lines to state.c. Could you rerun
>>>>>>
>>>>> your
>>>>> script and append also '/etc/asound.state' file and output from
>>>>>> 'alsa-info.sh --no-upload' to your output tarballs? Send me this
>>>>>> tarball
>>>>>> privately or just an URL to this list.
>>>>>>
>>>>>>                                       Thanks,
>>>>>>                                                Jaroslav
>>>>>>
>>>>>>
>>>>>>  did alsactl restore those IFACE_PCM volume since they are supposed at
>>>>> 0dB
>>>>>
>>>> by
>>>>
>>>>> default whenever the subdevice is open ?
>>>>>
>>>>> store the values in asound.state seem to be for debugging only
>>>>>
>>>>>    control.61 {
>>>>>        comment.access 'read write inactive'
>>>>>        comment.type INTEGER
>>>>>        comment.count 2
>>>>>        comment.range '0 - 32768'
>>>>>        iface PCM
>>>>>        subdevice 1
>>>>>        name 'PCM Playback Volume'
>>>>>        value.0 26214
>>>>>        value.1 26214
>>>>>    }
>>>>>
>>>> In fact, alsactl seems to restore the volume levels (despite the
>>>> "Unknown hardware" message) when the system is up and running, but it
>>>> does not restore the PCM and master levels at boot time. This should be
>>>> done when the hardware is detected by udev, as I have the following udev
>>>> rule:
>>>>
>>>> KERNEL=="controlC[0-9]*", ACTION=="add", RUN+="/usr/sbin/alsactl restore
>>>> %n"
>>>>
>>>>
>>>> Angel Tsankov
>>>>
>>>>
>>>>  Can you store the iface PCM "PCM Playback Volume" in asound.state while
>>> you
>>> are playing audio ?
>>>
>>> alsactl can store the value since the control is active when the subdevice
>>> is open
>>>
>>> alsactl already skip restoring of those control when it is not active , so
>>> the problem seem not related to those controls
>>>
>>> However via82xx also have those hardware specific controls
>>>
>> It seems that when I store the values while the sound card is playing I get
>> one more control in asound.state (see attached archive).
>>
>> Here's the test I did:
>>
>> 1. I removed /etc/asound.state (just in case);
>> 2. I made sure the sound card is not playing, ran 'alsactl store', and
>> renamed /etc/asound.state to /etc/asound.state.not-playing;
>> 3. I started vlc, played some music, ran 'alsactl store' once again, and
>> renamed /etc/asound.state to /etc/asound.state.playing;
>>
>> Then I diff'ed the two files and found out that they are different. I'm
>> sending them as alsactl created them.
>>
>>
>> Regards,
>> Angel Tsankov
>>
> 
> 
> This is the extra control saved when you are playing audio on subdevice 0
> 
> 
>     control.48 {
>         comment.access 'read write'
>         comment.type INTEGER
>         comment.count 2
>         comment.range '0 - 32768'
>         iface PCM
>         name 'PCM Playback Volume'
>         value.0 32768
>         value.1 32768
>     }
> 
> This look like there is any sound (login/system boot event sound)  playing
> when you perform alsactl restore , the driver will contain more control than
> state file , it will not restore but perform initialization

Here's another test I performed. I created a new /etc/asound.state while 
vlc was playing some music.  Then I made sure that control.48 is in the 
file and ensured the file won't be overridden at system shutdown.  Then 
I restarted the system, verified that the file's time stamp has not been 
changed and started Xfce's mixer only to discover that neither PCM, nor 
master volume was restored to its saved state. Rather, they looked more 
like initialized.

I'd also like to point out that in /etc/asound.state the values for 
control.48 are the maximum possible (if I interpret the values right), 
but when I stored the levels neither master, nor PCM was set to its 
maximum value.

Now, one test more. While playing some music I ran 'alsactl restore' and 
  both master and PCM levels were restored to the saved values.

Stil another test. While *not* playing anything I changed the master and 
PCM levels and ran 'alactl restore' and guess what... the levels were 
restored to their saved values!

Maybe the problem does not have anything to do with whether anything is 
being played while the levels are being restored or not and I still 
suspect that something might be wrong in my shutdown, or more likely -- 
boot-up, settings...


Regards,
Angel Tsankov

Re: alsactl restore: unknown hardware: ymf724f

[Angel Tsankov]

Angel Tsankov wrote:
> Raymond Yau wrote:
>> 2010/2/27 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
>>
>>> Raymond Yau wrote:
>>>
>>>> 2010/2/26 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
>>>>
>>>>  Raymond Yau wrote:
>>>>>> 2010/2/25 Jaroslav Kysela <perex@perex.cz>
>>>>>>
>>>>>>  On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>>>>  Jaroslav Kysela wrote:
>>>>>>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>>>>>>
>>>>>>>>>  Hello,
>>>>>>>>>> I run 'alsactl restore' on a machine with 2 sound cards -- a
>>>>>>>>>> built-in
>>>>>>>>>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller
>>>>>>>>>> (rev
>>>>>>>>>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
>>>>>>>>>> Controller] (rev 03) -- and get the following message:
>>>>>>>>>>
>>>>>>>>>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84"
>>>>>>>>>>
>>>>>>>>> "AC97a:83847600"
>>>>>> "0x1073" "0x000d"
>>>>>>>>>> Hardware is initialized using a guess method
>>>>>>>>>>
>>>>>>>>>> As a consequence the volume levels of the Yamaha card do not get
>>>>>>>>>> restored to the levels stored in /etc/asound.state.  The volume
>>>>>>>>>>
>>>>>>>>> levels
>>>>>> of the built-in card however are properly restored.  The asound.state
>>>>>>>>>> file has been created by executing 'alsactl store'.
>>>>>>>>>>
>>>>>>>>>> The kernel has been built with support for ALSA.  I've built and
>>>>>>>>>> installed the kernel modules for both cards (not the ones in the
>>>>>>>>>> alsa-driver package but those that come with kernel version
>>>>>>>>>>
>>>>>>>>> 2.6.30.2).
>>>>>> Any ideas why alsactl cannot find the hardware it has previously
>>>>>>>>>> identified as "YMF724F", "SigmaTel STAC9700,83,84", and so on?
>>>>>>>>>>
>>>>>>>>> The logic of alsactl is to restore the state from /etc/asound.state
>>>>>>>>> if
>>>>>>>>>
>>>>>>>> it
>>>>>>>> is valid. It seems like the set_controls() function in alsactl/state.c
>>>>>>>>> returns an error code for a reason.
>>>>>>>>>
>>>>>>>>> Could you try to compile the latest alsa-utils snapshot
>>>>>>>>> (http://www.alsa-project.org/snapshot/) and run './alsactl -d
>>>>>>>>>
>>>>>>>> restore'
>>>>>> in
>>>>>>>> alsa-utils/alsactl directory? A warning (fail reason) should be
>>>>>>>> printed.
>>>>>> I've attached a bash shell script that I used to download, configure,
>>>>>>>> compile, and run alsactl.  I've also attached a .log file with stdout
>>>>>>>>
>>>>>>> and
>>>>>> stderr that I got while executing the script.
>>>>>>> Thanks. I've added more debug print lines to state.c. Could you rerun
>>>>>>>
>>>>>> your
>>>>>> script and append also '/etc/asound.state' file and output from
>>>>>>> 'alsa-info.sh --no-upload' to your output tarballs? Send me this
>>>>>>> tarball
>>>>>>> privately or just an URL to this list.
>>>>>>>
>>>>>>>                                       Thanks,
>>>>>>>                                                Jaroslav
>>>>>>>
>>>>>>>
>>>>>>>  did alsactl restore those IFACE_PCM volume since they are supposed at
>>>>>> 0dB
>>>>>>
>>>>> by
>>>>>
>>>>>> default whenever the subdevice is open ?
>>>>>>
>>>>>> store the values in asound.state seem to be for debugging only
>>>>>>
>>>>>>    control.61 {
>>>>>>        comment.access 'read write inactive'
>>>>>>        comment.type INTEGER
>>>>>>        comment.count 2
>>>>>>        comment.range '0 - 32768'
>>>>>>        iface PCM
>>>>>>        subdevice 1
>>>>>>        name 'PCM Playback Volume'
>>>>>>        value.0 26214
>>>>>>        value.1 26214
>>>>>>    }
>>>>>>
>>>>> In fact, alsactl seems to restore the volume levels (despite the
>>>>> "Unknown hardware" message) when the system is up and running, but it
>>>>> does not restore the PCM and master levels at boot time. This should be
>>>>> done when the hardware is detected by udev, as I have the following udev
>>>>> rule:
>>>>>
>>>>> KERNEL=="controlC[0-9]*", ACTION=="add", RUN+="/usr/sbin/alsactl restore
>>>>> %n"
>>>>>
>>>>>
>>>>> Angel Tsankov
>>>>>
>>>>>
>>>>>  Can you store the iface PCM "PCM Playback Volume" in asound.state while
>>>> you
>>>> are playing audio ?
>>>>
>>>> alsactl can store the value since the control is active when the subdevice
>>>> is open
>>>>
>>>> alsactl already skip restoring of those control when it is not active , so
>>>> the problem seem not related to those controls
>>>>
>>>> However via82xx also have those hardware specific controls
>>>>
>>> It seems that when I store the values while the sound card is playing I get
>>> one more control in asound.state (see attached archive).
>>>
>>> Here's the test I did:
>>>
>>> 1. I removed /etc/asound.state (just in case);
>>> 2. I made sure the sound card is not playing, ran 'alsactl store', and
>>> renamed /etc/asound.state to /etc/asound.state.not-playing;
>>> 3. I started vlc, played some music, ran 'alsactl store' once again, and
>>> renamed /etc/asound.state to /etc/asound.state.playing;
>>>
>>> Then I diff'ed the two files and found out that they are different. I'm
>>> sending them as alsactl created them.
>>>
>>>
>>> Regards,
>>> Angel Tsankov
>>>
>>
>> This is the extra control saved when you are playing audio on subdevice 0
>>
>>
>>     control.48 {
>>         comment.access 'read write'
>>         comment.type INTEGER
>>         comment.count 2
>>         comment.range '0 - 32768'
>>         iface PCM
>>         name 'PCM Playback Volume'
>>         value.0 32768
>>         value.1 32768
>>     }
>>
>> This look like there is any sound (login/system boot event sound)  playing
>> when you perform alsactl restore , the driver will contain more control than
>> state file , it will not restore but perform initialization
> 
> Here's another test I performed. I created a new /etc/asound.state while 
> vlc was playing some music.  Then I made sure that control.48 is in the 
> file and ensured the file won't be overridden at system shutdown.  Then 
> I restarted the system, verified that the file's time stamp has not been 
> changed and started Xfce's mixer only to discover that neither PCM, nor 
> master volume was restored to its saved state. Rather, they looked more 
> like initialized.
> 
> I'd also like to point out that in /etc/asound.state the values for 
> control.48 are the maximum possible (if I interpret the values right), 
> but when I stored the levels neither master, nor PCM was set to its 
> maximum value.
> 
> Now, one test more. While playing some music I ran 'alsactl restore' and 
>   both master and PCM levels were restored to the saved values.
> 
> Stil another test. While *not* playing anything I changed the master and 
> PCM levels and ran 'alactl restore' and guess what... the levels were 
> restored to their saved values!

Some additional info: I performed the above tests with an 
/etc/asound.state file created while nothing is being played and which 
did not have control.48 in it and I got the same results -- the master 
and PCM levels were restored regardless of whether anything is being 
played when I ran 'aslactl restore'.

> Maybe the problem does not have anything to do with whether anything is 
> being played while the levels are being restored or not and I still 
> suspect that something might be wrong in my shutdown, or more likely -- 
> boot-up, settings...

Now my suspicion seems more logically sound.


Angel Tsankov

Re: alsactl restore: unknown hardware: ymf724f

[Raymond Yau]

2010/2/27 Angel Tsankov <fn42551@fmi.uni-sofia.bg>

> Raymond Yau wrote:
> > 2010/2/27 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
> >
> >> Raymond Yau wrote:
> >>
> >>> 2010/2/26 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
> >>>
> >>>  Raymond Yau wrote:
> >>>>> 2010/2/25 Jaroslav Kysela <perex@perex.cz>
> >>>>>
> >>>>>  On Thu, 25 Feb 2010, Angel Tsankov wrote:
> >>>>>>  Jaroslav Kysela wrote:
> >>>>>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
> >>>>>>>>
> >>>>>>>>  Hello,
> >>>>>>>>> I run 'alsactl restore' on a machine with 2 sound cards -- a
> >>>>>>>>> built-in
> >>>>>>>>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller
> >>>>>>>>> (rev
> >>>>>>>>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
> >>>>>>>>> Controller] (rev 03) -- and get the following message:
> >>>>>>>>>
> >>>>>>>>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84"
> >>>>>>>>>
> >>>>>>>> "AC97a:83847600"
> >>>>> "0x1073" "0x000d"
> >>>>>>>>> Hardware is initialized using a guess method
> >>>>>>>>>
> >>>>>>>>> As a consequence the volume levels of the Yamaha card do not get
> >>>>>>>>> restored to the levels stored in /etc/asound.state.  The volume
> >>>>>>>>>
> >>>>>>>> levels
> >>>>> of the built-in card however are properly restored.  The asound.state
> >>>>>>>>> file has been created by executing 'alsactl store'.
> >>>>>>>>>
> >>>>>>>>> The kernel has been built with support for ALSA.  I've built and
> >>>>>>>>> installed the kernel modules for both cards (not the ones in the
> >>>>>>>>> alsa-driver package but those that come with kernel version
> >>>>>>>>>
> >>>>>>>> 2.6.30.2).
> >>>>> Any ideas why alsactl cannot find the hardware it has previously
> >>>>>>>>> identified as "YMF724F", "SigmaTel STAC9700,83,84", and so on?
> >>>>>>>>>
> >>>>>>>> The logic of alsactl is to restore the state from
> /etc/asound.state
> >>>>>>>> if
> >>>>>>>>
> >>>>>>> it
> >>>>>>> is valid. It seems like the set_controls() function in
> alsactl/state.c
> >>>>>>>> returns an error code for a reason.
> >>>>>>>>
> >>>>>>>> Could you try to compile the latest alsa-utils snapshot
> >>>>>>>> (http://www.alsa-project.org/snapshot/) and run './alsactl -d
> >>>>>>>>
> >>>>>>> restore'
> >>>>> in
> >>>>>>> alsa-utils/alsactl directory? A warning (fail reason) should be
> >>>>>>> printed.
> >>>>> I've attached a bash shell script that I used to download, configure,
> >>>>>>> compile, and run alsactl.  I've also attached a .log file with
> stdout
> >>>>>>>
> >>>>>> and
> >>>>> stderr that I got while executing the script.
> >>>>>> Thanks. I've added more debug print lines to state.c. Could you
> rerun
> >>>>>>
> >>>>> your
> >>>>> script and append also '/etc/asound.state' file and output from
> >>>>>> 'alsa-info.sh --no-upload' to your output tarballs? Send me this
> >>>>>> tarball
> >>>>>> privately or just an URL to this list.
> >>>>>>
> >>>>>>                                       Thanks,
> >>>>>>                                                Jaroslav
> >>>>>>
> >>>>>>
> >>>>>>  did alsactl restore those IFACE_PCM volume since they are supposed
> at
> >>>>> 0dB
> >>>>>
> >>>> by
> >>>>
> >>>>> default whenever the subdevice is open ?
> >>>>>
> >>>>> store the values in asound.state seem to be for debugging only
> >>>>>
> >>>>>    control.61 {
> >>>>>        comment.access 'read write inactive'
> >>>>>        comment.type INTEGER
> >>>>>        comment.count 2
> >>>>>        comment.range '0 - 32768'
> >>>>>        iface PCM
> >>>>>        subdevice 1
> >>>>>        name 'PCM Playback Volume'
> >>>>>        value.0 26214
> >>>>>        value.1 26214
> >>>>>    }
> >>>>>
> >>>> In fact, alsactl seems to restore the volume levels (despite the
> >>>> "Unknown hardware" message) when the system is up and running, but it
> >>>> does not restore the PCM and master levels at boot time. This should
> be
> >>>> done when the hardware is detected by udev, as I have the following
> udev
> >>>> rule:
> >>>>
> >>>> KERNEL=="controlC[0-9]*", ACTION=="add", RUN+="/usr/sbin/alsactl
> restore
> >>>> %n"
> >>>>
> >>>>
> >>>> Angel Tsankov
> >>>>
> >>>>
> >>>>  Can you store the iface PCM "PCM Playback Volume" in asound.state
> while
> >>> you
> >>> are playing audio ?
> >>>
> >>> alsactl can store the value since the control is active when the
> subdevice
> >>> is open
> >>>
> >>> alsactl already skip restoring of those control when it is not active ,
> so
> >>> the problem seem not related to those controls
> >>>
> >>> However via82xx also have those hardware specific controls
> >>>
> >> It seems that when I store the values while the sound card is playing I
> get
> >> one more control in asound.state (see attached archive).
> >>
> >> Here's the test I did:
> >>
> >> 1. I removed /etc/asound.state (just in case);
> >> 2. I made sure the sound card is not playing, ran 'alsactl store', and
> >> renamed /etc/asound.state to /etc/asound.state.not-playing;
> >> 3. I started vlc, played some music, ran 'alsactl store' once again, and
> >> renamed /etc/asound.state to /etc/asound.state.playing;
> >>
> >> Then I diff'ed the two files and found out that they are different. I'm
> >> sending them as alsactl created them.
> >>
> >>
> >> Regards,
> >> Angel Tsankov
> >>
> >
> >
> > This is the extra control saved when you are playing audio on subdevice 0
> >
> >
> >     control.48 {
> >         comment.access 'read write'
> >         comment.type INTEGER
> >         comment.count 2
> >         comment.range '0 - 32768'
> >         iface PCM
> >         name 'PCM Playback Volume'
> >         value.0 32768
> >         value.1 32768
> >     }
> >
> > This look like there is any sound (login/system boot event sound)
>  playing
> > when you perform alsactl restore , the driver will contain more control
> than
> > state file , it will not restore but perform initialization
>
> Here's another test I performed. I created a new /etc/asound.state while
> vlc was playing some music.  Then I made sure that control.48 is in the
> file and ensured the file won't be overridden at system shutdown.  Then
> I restarted the system, verified that the file's time stamp has not been
> changed and started Xfce's mixer only to discover that neither PCM, nor
> master volume was restored to its saved state. Rather, they looked more
> like initialized.
>
> I'd also like to point out that in /etc/asound.state the values for
> control.48 are the maximum possible (if I interpret the values right),
> but when I stored the levels neither master, nor PCM was set to its
> maximum value.
>
> Now, one test more. While playing some music I ran 'alsactl restore' and
>  both master and PCM levels were restored to the saved values.
>
> Stil another test. While *not* playing anything I changed the master and
> PCM levels and ran 'alactl restore' and guess what... the levels were
> restored to their saved values!
>
> Maybe the problem does not have anything to do with whether anything is
> being played while the levels are being restored or not and I still
> suspect that something might be wrong in my shutdown, or more likely --
> boot-up, settings...
>
>
> Regards,
> Angel Tsankov
>  <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>
>


I guess that the purpose of that patch is used for those Live CD which did
not has asound.state , therefore sound will initialised to an audible volume
by using alsactl restore

When the driver has more controls than asound.state ( no controls in asound
state)

if  there is no sound playing when system shut down , the control will not
be saved

However if there is system event sound playing or an application open the
sound card while alsactl restore from asound.state  ( ymfpci and via82xx
will have one controls more than the state file , alsactl restore will
initialised to to an audible volume instead of  restore the values from
asound.state








> l <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>
>

Re: alsactl restore: unknown hardware: ymf724f

[Raymond Yau]

2010/2/27 Angel Tsankov <fn42551@fmi.uni-sofia.bg>

>
> I'd also like to point out that in /etc/asound.state the values for
> control.48 are the maximum possible (if I interpret the values right),
> but when I stored the levels neither master, nor PCM was set to its
> maximum value.
>
> Regards,
> Angel Tsankov
>
>
That is the per voice volume control which use the hardware mixer in ymf754
chip instead of the mixer of ac97 codec

ymf754 has 32 playback subdevices , each subdevices has one hardware mixer
volume control

the values are set to 0dB by the driver when the subdevice is open , DSP can
mix 32 streams by hardware

when  the driver is loaded there are 32 controls which are inactive and the
total number of controls should more that those controls in asound.state
since those iface PCM "PCM playback volume controls" are not saved at
shutdown because all 32 controls are inactive when 32 subdevices are closed

Re: alsactl restore: unknown hardware: ymf724f

[Angel Tsankov]

Raymond Yau wrote:
> 2010/2/27 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
> 
>> I'd also like to point out that in /etc/asound.state the values for
>> control.48 are the maximum possible (if I interpret the values right),
>> but when I stored the levels neither master, nor PCM was set to its
>> maximum value.
>>
>> Regards,
>> Angel Tsankov
>>
>>
> That is the per voice volume control which use the hardware mixer in ymf754

The device in question is YMF724F.

> chip instead of the mixer of ac97 codec
> 
> ymf754 has 32 playback subdevices , each subdevices has one hardware mixer
> volume control
> 
> the values are set to 0dB by the driver when the subdevice is open , DSP can
> mix 32 streams by hardware
> 
> when  the driver is loaded there are 32 controls which are inactive and the
> total number of controls should more that those controls in asound.state
> since those iface PCM "PCM playback volume controls" are not saved at
> shutdown because all 32 controls are inactive when 32 subdevices are closed

Angel Tsankov

Re: alsactl restore: unknown hardware: ymf724f

[Angel Tsankov]

Angel Tsankov wrote:
> Angel Tsankov wrote:
>> Raymond Yau wrote:
>>> 2010/2/27 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
>>>
>>>> Raymond Yau wrote:
>>>>
>>>>> 2010/2/26 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
>>>>>
>>>>>  Raymond Yau wrote:
>>>>>>> 2010/2/25 Jaroslav Kysela <perex@perex.cz>
>>>>>>>
>>>>>>>  On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>>>>>  Jaroslav Kysela wrote:
>>>>>>>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>>>>>>>
>>>>>>>>>>  Hello,
>>>>>>>>>>> I run 'alsactl restore' on a machine with 2 sound cards -- a
>>>>>>>>>>> built-in
>>>>>>>>>>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller
>>>>>>>>>>> (rev
>>>>>>>>>>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
>>>>>>>>>>> Controller] (rev 03) -- and get the following message:
>>>>>>>>>>>
>>>>>>>>>>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84"
>>>>>>>>>>>
>>>>>>>>>> "AC97a:83847600"
>>>>>>> "0x1073" "0x000d"
>>>>>>>>>>> Hardware is initialized using a guess method
>>>>>>>>>>>
>>>>>>>>>>> As a consequence the volume levels of the Yamaha card do not get
>>>>>>>>>>> restored to the levels stored in /etc/asound.state.  The volume
>>>>>>>>>>>
>>>>>>>>>> levels
>>>>>>> of the built-in card however are properly restored.  The asound.state
>>>>>>>>>>> file has been created by executing 'alsactl store'.
>>>>>>>>>>>
>>>>>>>>>>> The kernel has been built with support for ALSA.  I've built and
>>>>>>>>>>> installed the kernel modules for both cards (not the ones in the
>>>>>>>>>>> alsa-driver package but those that come with kernel version
>>>>>>>>>>>
>>>>>>>>>> 2.6.30.2).
>>>>>>> Any ideas why alsactl cannot find the hardware it has previously
>>>>>>>>>>> identified as "YMF724F", "SigmaTel STAC9700,83,84", and so on?
>>>>>>>>>>>
>>>>>>>>>> The logic of alsactl is to restore the state from /etc/asound.state
>>>>>>>>>> if
>>>>>>>>>>
>>>>>>>>> it
>>>>>>>>> is valid. It seems like the set_controls() function in alsactl/state.c
>>>>>>>>>> returns an error code for a reason.
>>>>>>>>>>
>>>>>>>>>> Could you try to compile the latest alsa-utils snapshot
>>>>>>>>>> (http://www.alsa-project.org/snapshot/) and run './alsactl -d
>>>>>>>>>>
>>>>>>>>> restore'
>>>>>>> in
>>>>>>>>> alsa-utils/alsactl directory? A warning (fail reason) should be
>>>>>>>>> printed.
>>>>>>> I've attached a bash shell script that I used to download, configure,
>>>>>>>>> compile, and run alsactl.  I've also attached a .log file with stdout
>>>>>>>>>
>>>>>>>> and
>>>>>>> stderr that I got while executing the script.
>>>>>>>> Thanks. I've added more debug print lines to state.c. Could you rerun
>>>>>>>>
>>>>>>> your
>>>>>>> script and append also '/etc/asound.state' file and output from
>>>>>>>> 'alsa-info.sh --no-upload' to your output tarballs? Send me this
>>>>>>>> tarball
>>>>>>>> privately or just an URL to this list.
>>>>>>>>
>>>>>>>>                                       Thanks,
>>>>>>>>                                                Jaroslav
>>>>>>>>
>>>>>>>>
>>>>>>>>  did alsactl restore those IFACE_PCM volume since they are supposed at
>>>>>>> 0dB
>>>>>>>
>>>>>> by
>>>>>>
>>>>>>> default whenever the subdevice is open ?
>>>>>>>
>>>>>>> store the values in asound.state seem to be for debugging only
>>>>>>>
>>>>>>>    control.61 {
>>>>>>>        comment.access 'read write inactive'
>>>>>>>        comment.type INTEGER
>>>>>>>        comment.count 2
>>>>>>>        comment.range '0 - 32768'
>>>>>>>        iface PCM
>>>>>>>        subdevice 1
>>>>>>>        name 'PCM Playback Volume'
>>>>>>>        value.0 26214
>>>>>>>        value.1 26214
>>>>>>>    }
>>>>>>>
>>>>>> In fact, alsactl seems to restore the volume levels (despite the
>>>>>> "Unknown hardware" message) when the system is up and running, but it
>>>>>> does not restore the PCM and master levels at boot time. This should be
>>>>>> done when the hardware is detected by udev, as I have the following udev
>>>>>> rule:
>>>>>>
>>>>>> KERNEL=="controlC[0-9]*", ACTION=="add", RUN+="/usr/sbin/alsactl restore
>>>>>> %n"
>>>>>>
>>>>>>
>>>>>> Angel Tsankov
>>>>>>
>>>>>>
>>>>>>  Can you store the iface PCM "PCM Playback Volume" in asound.state while
>>>>> you
>>>>> are playing audio ?
>>>>>
>>>>> alsactl can store the value since the control is active when the subdevice
>>>>> is open
>>>>>
>>>>> alsactl already skip restoring of those control when it is not active , so
>>>>> the problem seem not related to those controls
>>>>>
>>>>> However via82xx also have those hardware specific controls
>>>>>
>>>> It seems that when I store the values while the sound card is playing I get
>>>> one more control in asound.state (see attached archive).
>>>>
>>>> Here's the test I did:
>>>>
>>>> 1. I removed /etc/asound.state (just in case);
>>>> 2. I made sure the sound card is not playing, ran 'alsactl store', and
>>>> renamed /etc/asound.state to /etc/asound.state.not-playing;
>>>> 3. I started vlc, played some music, ran 'alsactl store' once again, and
>>>> renamed /etc/asound.state to /etc/asound.state.playing;
>>>>
>>>> Then I diff'ed the two files and found out that they are different. I'm
>>>> sending them as alsactl created them.
>>>>
>>>>
>>>> Regards,
>>>> Angel Tsankov
>>>>
>>> This is the extra control saved when you are playing audio on subdevice 0
>>>
>>>
>>>     control.48 {
>>>         comment.access 'read write'
>>>         comment.type INTEGER
>>>         comment.count 2
>>>         comment.range '0 - 32768'
>>>         iface PCM
>>>         name 'PCM Playback Volume'
>>>         value.0 32768
>>>         value.1 32768
>>>     }
>>>
>>> This look like there is any sound (login/system boot event sound)  playing
>>> when you perform alsactl restore , the driver will contain more control than
>>> state file , it will not restore but perform initialization
>> Here's another test I performed. I created a new /etc/asound.state while 
>> vlc was playing some music.  Then I made sure that control.48 is in the 
>> file and ensured the file won't be overridden at system shutdown.  Then 
>> I restarted the system, verified that the file's time stamp has not been 
>> changed and started Xfce's mixer only to discover that neither PCM, nor 
>> master volume was restored to its saved state. Rather, they looked more 
>> like initialized.
>>
>> I'd also like to point out that in /etc/asound.state the values for 
>> control.48 are the maximum possible (if I interpret the values right), 
>> but when I stored the levels neither master, nor PCM was set to its 
>> maximum value.
>>
>> Now, one test more. While playing some music I ran 'alsactl restore' and 
>>   both master and PCM levels were restored to the saved values.
>>
>> Stil another test. While *not* playing anything I changed the master and 
>> PCM levels and ran 'alactl restore' and guess what... the levels were 
>> restored to their saved values!
> 
> Some additional info: I performed the above tests with an 
> /etc/asound.state file created while nothing is being played and which 
> did not have control.48 in it and I got the same results -- the master 
> and PCM levels were restored regardless of whether anything is being 
> played when I ran 'aslactl restore'.
> 
>> Maybe the problem does not have anything to do with whether anything is 
>> being played while the levels are being restored or not and I still 
>> suspect that something might be wrong in my shutdown, or more likely -- 
>> boot-up, settings...
> 
> Now my suspicion seems more logically sound.

I fixed the problem by adding the following line to the udev rule for 
alsa devices:

KERNEL=="pcmC[0-9]*D**", ACTION=="add", RUN+="/usr/sbin/alsactl restore %n"



Regards,
Angel Tsankov

Re: alsactl restore: unknown hardware: ymf724f

[Raymond Yau]

2010/2/26 Pacho Ramos <pacho@condmat1.ciencias.uniovi.es>

> El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió:
> > Raymond Yau wrote:
> > > 2010/2/25 Jaroslav Kysela <perex@perex.cz>
> > >
> > >> On Thu, 25 Feb 2010, Angel Tsankov wrote:
> > >>
> > >>> Jaroslav Kysela wrote:
> > >>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
> > >>>>
> > >>>>> Hello,
> > >>>>>
> > >>>>> I run 'alsactl restore' on a machine with 2 sound cards -- a
> built-in
> > >>>>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller
> (rev
> > >>>>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
> > >>>>> Controller] (rev 03) -- and get the following message:
> > >>>>>
> > >>>>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84"
> "AC97a:83847600"
> > >>>>> "0x1073" "0x000d"
> > >>>>> Hardware is initialized using a guess method
> > >>>>>
> > >>>>> As a consequence the volume levels of the Yamaha card do not get
> > >>>>> restored to the levels stored in /etc/asound.state.  The volume
> levels
> > >>>>> of the built-in card however are properly restored.  The
> asound.state
> > >>>>> file has been created by executing 'alsactl store'.
> > >>>>>
> > >>>>> The kernel has been built with support for ALSA.  I've built and
> > >>>>> installed the kernel modules for both cards (not the ones in the
> > >>>>> alsa-driver package but those that come with kernel version
> 2.6.30.2).
> > >>>>> Any ideas why alsactl cannot find the hardware it has previously
> > >>>>> identified as "YMF724F", "SigmaTel STAC9700,83,84", and so on?
> > >>>> The logic of alsactl is to restore the state from /etc/asound.state
> if
> > >> it
> > >>>> is valid. It seems like the set_controls() function in
> alsactl/state.c
> > >>>> returns an error code for a reason.
> > >>>>
> > >>>> Could you try to compile the latest alsa-utils snapshot
> > >>>> (http://www.alsa-project.org/snapshot/) and run './alsactl -d
> restore'
> > >> in
> > >>>> alsa-utils/alsactl directory? A warning (fail reason) should be
> printed.
> > >>> I've attached a bash shell script that I used to download, configure,
> > >>> compile, and run alsactl.  I've also attached a .log file with stdout
> and
> > >>> stderr that I got while executing the script.
> > >> Thanks. I've added more debug print lines to state.c. Could you rerun
> your
> > >> script and append also '/etc/asound.state' file and output from
> > >> 'alsa-info.sh --no-upload' to your output tarballs? Send me this
> tarball
> > >> privately or just an URL to this list.
>
>
> Looks similar to my problem:
> http://www.spinics.net/lists/alsa-devel/msg31422.html
>
>
>
your problem is "alsactl restore" become "alsactl init" when the number of
controls is more than those in state file.

"Hardware is initialized using a guess method" instead of restore from
asound.state

alsactl -f /var/lib/alsa/asound.state restore
Unknown hardware: "VIA8237" "Realtek ALC658D" "AC97a:414c4781" "0x147b"
"0x1415"
Hardware is initialized using a guess method

Re: alsactl restore: unknown hardware: ymf724f

[Angel Tsankov]

Hello again!

I've recently had some time to investigate this problem further on and 
here's what I've discovered:

Raymond Yau wrote:
> 2010/2/26 Pacho Ramos <pacho@condmat1.ciencias.uniovi.es>
> 
>> El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió:
>>> Raymond Yau wrote:
>>>> 2010/2/25 Jaroslav Kysela <perex@perex.cz>
>>>>
>>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>>
>>>>>> Jaroslav Kysela wrote:
>>>>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I run 'alsactl restore' on a machine with 2 sound cards -- a
>> built-in
>>>>>>>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller
>> (rev
>>>>>>>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
>>>>>>>> Controller] (rev 03) -- and get the following message:
>>>>>>>>
>>>>>>>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84"
>> "AC97a:83847600"
>>>>>>>> "0x1073" "0x000d"
>>>>>>>> Hardware is initialized using a guess method
>>>>>>>>
>>>>>>>> As a consequence the volume levels of the Yamaha card do not get
>>>>>>>> restored to the levels stored in /etc/asound.state.  The volume
>> levels
>>>>>>>> of the built-in card however are properly restored.  The
>> asound.state
>>>>>>>> file has been created by executing 'alsactl store'.
>>>>>>>>
>>>>>>>> The kernel has been built with support for ALSA.  I've built and
>>>>>>>> installed the kernel modules for both cards (not the ones in the
>>>>>>>> alsa-driver package but those that come with kernel version
>> 2.6.30.2).
>>>>>>>> Any ideas why alsactl cannot find the hardware it has previously
>>>>>>>> identified as "YMF724F", "SigmaTel STAC9700,83,84", and so on?
>>>>>>> The logic of alsactl is to restore the state from /etc/asound.state
>> if
>>>>> it
>>>>>>> is valid. It seems like the set_controls() function in
>> alsactl/state.c
>>>>>>> returns an error code for a reason.
>>>>>>>
>>>>>>> Could you try to compile the latest alsa-utils snapshot
>>>>>>> (http://www.alsa-project.org/snapshot/) and run './alsactl -d
>> restore'
>>>>> in
>>>>>>> alsa-utils/alsactl directory? A warning (fail reason) should be
>> printed.
>>>>>> I've attached a bash shell script that I used to download, configure,
>>>>>> compile, and run alsactl.  I've also attached a .log file with stdout
>> and
>>>>>> stderr that I got while executing the script.
>>>>> Thanks. I've added more debug print lines to state.c. Could you rerun
>> your
>>>>> script and append also '/etc/asound.state' file and output from
>>>>> 'alsa-info.sh --no-upload' to your output tarballs? Send me this
>> tarball
>>>>> privately or just an URL to this list.
>>
>> Looks similar to my problem:
>> http://www.spinics.net/lists/alsa-devel/msg31422.html
>>
>>
>>
> your problem is "alsactl restore" become "alsactl init" when the number of
> controls is more than those in state file.

I'm not quite sure that the case is this since 'alsactl restore' does 
restore the values of the Yamaha sound card (and those of the other 
card, too) and 'alsactl restore 1' seems to just initialize the Yamaha 
card.  This is with alsa-utils version 1.0.22.


Regards,

Angel Tsankov

Re: alsactl restore: unknown hardware: ymf724f

[Raymond Yau]

2010/3/26 Angel Tsankov <fn42551@fmi.uni-sofia.bg>

> Hello again!
>
> I've recently had some time to investigate this problem further on and
> here's what I've discovered:
>
> Raymond Yau wrote:
> > 2010/2/26 Pacho Ramos <pacho@condmat1.ciencias.uniovi.es>
> >
> >> El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió:
> >>> Raymond Yau wrote:
> >>>> 2010/2/25 Jaroslav Kysela <perex@perex.cz>
> >>>>
> >>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
> >>>>>
> >>>>>> Jaroslav Kysela wrote:
> >>>>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
> >>>>>>>
> >>>>>>>> Hello,
> >>>>>>>>
> >>>>>>>> I run 'alsactl restore' on a machine with 2 sound cards -- a
> >> built-in
> >>>>>>>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller
> >> (rev
> >>>>>>>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
> >>>>>>>> Controller] (rev 03) -- and get the following message:
> >>>>>>>>
> >>>>>>>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84"
> >> "AC97a:83847600"
> >>>>>>>> "0x1073" "0x000d"
> >>>>>>>> Hardware is initialized using a guess method
> >>>>>>>>
> >>>>>>>> As a consequence the volume levels of the Yamaha card do not get
> >>>>>>>> restored to the levels stored in /etc/asound.state.  The volume
> >> levels
> >>>>>>>> of the built-in card however are properly restored.  The
> >> asound.state
> >>>>>>>> file has been created by executing 'alsactl store'.
> >>>>>>>>
>
> >>
> > your problem is "alsactl restore" become "alsactl init" when the number
> of
> > controls is more than those in state file.
>
> I'm not quite sure that the case is this since 'alsactl restore' does
> restore the values of the Yamaha sound card (and those of the other
> card, too) and 'alsactl restore 1' seems to just initialize the Yamaha
> card.  This is with alsa-utils version 1.0.22.
>
>
> Regards,
>
> Angel Tsankov
>
>
"Hardware is initialized using a guess method "  is the message used by
alsactl init

http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=9a748178d1c9e783242f0cc794ab3efb27092f34;hp=0c02a4e3d23c7b5d03215f1bfaba9f70ed11e9b7

Re: alsactl restore: unknown hardware: ymf724f

[Angel Tsankov]

Raymond Yau wrote:
> 2010/3/26 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
> 
>> Hello again!
>>
>> I've recently had some time to investigate this problem further on and
>> here's what I've discovered:
>>
>> Raymond Yau wrote:
>>> 2010/2/26 Pacho Ramos <pacho@condmat1.ciencias.uniovi.es>
>>>
>>>> El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió:
>>>>> Raymond Yau wrote:
>>>>>> 2010/2/25 Jaroslav Kysela <perex@perex.cz>
>>>>>>
>>>>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>>>>
>>>>>>>> Jaroslav Kysela wrote:
>>>>>>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> I run 'alsactl restore' on a machine with 2 sound cards -- a
>>>> built-in
>>>>>>>>>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller
>>>> (rev
>>>>>>>>>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
>>>>>>>>>> Controller] (rev 03) -- and get the following message:
>>>>>>>>>>
>>>>>>>>>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84"
>>>> "AC97a:83847600"
>>>>>>>>>> "0x1073" "0x000d"
>>>>>>>>>> Hardware is initialized using a guess method
>>>>>>>>>>
>>>>>>>>>> As a consequence the volume levels of the Yamaha card do not get
>>>>>>>>>> restored to the levels stored in /etc/asound.state.  The volume
>>>> levels
>>>>>>>>>> of the built-in card however are properly restored.  The
>>>> asound.state
>>>>>>>>>> file has been created by executing 'alsactl store'.
>>>>>>>>>>
>>> your problem is "alsactl restore" become "alsactl init" when the number
>> of
>>> controls is more than those in state file.
>> I'm not quite sure that the case is this since 'alsactl restore' does
>> restore the values of the Yamaha sound card (and those of the other
>> card, too) and 'alsactl restore 1' seems to just initialize the Yamaha
>> card.  This is with alsa-utils version 1.0.22.
>>
> "Hardware is initialized using a guess method "  is the message used by
> alsactl init
> 
> http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=9a748178d1c9e783242f0cc794ab3efb27092f34;hp=0c02a4e3d23c7b5d03215f1bfaba9f70ed11e9b7

I don't get what you mean. Could you explain a little bit more?


Regards,
Angel Tsankov

Re: alsactl restore: unknown hardware: ymf724f

[Raymond Yau]

2010/3/29 Angel Tsankov <fn42551@fmi.uni-sofia.bg>

> Raymond Yau wrote:
> > 2010/3/26 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
> >
> >> Hello again!
> >>
> >> I've recently had some time to investigate this problem further on and
> >> here's what I've discovered:
> >>
> >> Raymond Yau wrote:
> >>> 2010/2/26 Pacho Ramos <pacho@condmat1.ciencias.uniovi.es>
> >>>
> >>>> El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió:
> >>>>> Raymond Yau wrote:
> >>>>>> 2010/2/25 Jaroslav Kysela <perex@perex.cz>
> >>>>>>
> >>>>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
> >>>>>>>
> >>>>>>>> Jaroslav Kysela wrote:
> >>>>>>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
> >>>>>>>>>
> >>>>>>>>>> Hello,
> >>>>>>>>>>
> >>>>>>>>>> I run 'alsactl restore' on a machine with 2 sound cards -- a
> >>>> built-in
> >>>>>>>>>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller
> >>>> (rev
> >>>>>>>>>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
> >>>>>>>>>> Controller] (rev 03) -- and get the following message:
> >>>>>>>>>>
> >>>>>>>>>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84"
> >>>> "AC97a:83847600"
> >>>>>>>>>> "0x1073" "0x000d"
> >>>>>>>>>> Hardware is initialized using a guess method
> >>>>>>>>>>
> >>>>>>>>>> As a consequence the volume levels of the Yamaha card do not get
> >>>>>>>>>> restored to the levels stored in /etc/asound.state.  The volume
> >>>> levels
> >>>>>>>>>> of the built-in card however are properly restored.  The
> >>>> asound.state
> >>>>>>>>>> file has been created by executing 'alsactl store'.
> >>>>>>>>>>
> >>> your problem is "alsactl restore" become "alsactl init" when the number
> >> of
> >>> controls is more than those in state file.
> >> I'm not quite sure that the case is this since 'alsactl restore' does
> >> restore the values of the Yamaha sound card (and those of the other
> >> card, too) and 'alsactl restore 1' seems to just initialize the Yamaha
> >> card.  This is with alsa-utils version 1.0.22.
> >>
> > "Hardware is initialized using a guess method "  is the message used by
> > alsactl init
> >
> >
> http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=9a748178d1c9e783242f0cc794ab3efb27092f34;hp=0c02a4e3d23c7b5d03215f1bfaba9f70ed11e9b7
>
> I don't get what you mean. Could you explain a little bit more?
>
>
> Regards,
> Angel Tsankov
>
>
post the output of alsa-info.sh after  "alsactl init"

and immeditate after the system boot

Re: alsactl restore: unknown hardware: ymf724f

[Angel Tsankov]

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

Raymond Yau wrote:
> 2010/3/29 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
> 
>> Raymond Yau wrote:
>>> 2010/3/26 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
>>>
>>>> Hello again!
>>>>
>>>> I've recently had some time to investigate this problem further on and
>>>> here's what I've discovered:
>>>>
>>>> Raymond Yau wrote:
>>>>> 2010/2/26 Pacho Ramos <pacho@condmat1.ciencias.uniovi.es>
>>>>>
>>>>>> El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió:
>>>>>>> Raymond Yau wrote:
>>>>>>>> 2010/2/25 Jaroslav Kysela <perex@perex.cz>
>>>>>>>>
>>>>>>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>>>>>>
>>>>>>>>>> Jaroslav Kysela wrote:
>>>>>>>>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> I run 'alsactl restore' on a machine with 2 sound cards -- a
>>>>>> built-in
>>>>>>>>>>>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller
>>>>>> (rev
>>>>>>>>>>>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
>>>>>>>>>>>> Controller] (rev 03) -- and get the following message:
>>>>>>>>>>>>
>>>>>>>>>>>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84"
>>>>>> "AC97a:83847600"
>>>>>>>>>>>> "0x1073" "0x000d"
>>>>>>>>>>>> Hardware is initialized using a guess method
>>>>>>>>>>>>
>>>>>>>>>>>> As a consequence the volume levels of the Yamaha card do not get
>>>>>>>>>>>> restored to the levels stored in /etc/asound.state.  The volume
>>>>>> levels
>>>>>>>>>>>> of the built-in card however are properly restored.  The
>>>>>> asound.state
>>>>>>>>>>>> file has been created by executing 'alsactl store'.
>>>>>>>>>>>>
>>>>> your problem is "alsactl restore" become "alsactl init" when the number
>>>> of
>>>>> controls is more than those in state file.
>>>> I'm not quite sure that the case is this since 'alsactl restore' does
>>>> restore the values of the Yamaha sound card (and those of the other
>>>> card, too) and 'alsactl restore 1' seems to just initialize the Yamaha
>>>> card.  This is with alsa-utils version 1.0.22.
>>>>
>>> "Hardware is initialized using a guess method "  is the message used by
>>> alsactl init
>>>
>>>
>> http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=9a748178d1c9e783242f0cc794ab3efb27092f34;hp=0c02a4e3d23c7b5d03215f1bfaba9f70ed11e9b7
>>
>> I don't get what you mean. Could you explain a little bit more?
>>
> post the output of alsa-info.sh after  "alsactl init"
> 
> and immeditate after the system boot

I'm sending the requested output as an attachment.

Angel Tsankov

[-- Attachment #2: alsa-info.txt.tar.bz2 --]
[-- Type: application/octet-stream, Size: 5035 bytes --]

[-- Attachment #3: 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: alsactl restore: unknown hardware: ymf724f

[Raymond Yau]

2010/3/29 Angel Tsankov <fn42551@fmi.uni-sofia.bg>

> Raymond Yau wrote:
>
>> 2010/3/29 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
>>
>>  Raymond Yau wrote:
>>>
>>>> 2010/3/26 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
>>>>
>>>>  Hello again!
>>>>>
>>>>> I've recently had some time to investigate this problem further on and
>>>>> here's what I've discovered:
>>>>>
>>>>> Raymond Yau wrote:
>>>>>
>>>>>> 2010/2/26 Pacho Ramos <pacho@condmat1.ciencias.uniovi.es>
>>>>>>
>>>>>>  El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió:
>>>>>>>
>>>>>>>> Raymond Yau wrote:
>>>>>>>>
>>>>>>>>> 2010/2/25 Jaroslav Kysela <perex@perex.cz>
>>>>>>>>>
>>>>>>>>>  On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>>>>>>>
>>>>>>>>>>  Jaroslav Kysela wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>  Hello,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I run 'alsactl restore' on a machine with 2 sound cards -- a
>>>>>>>>>>>>>
>>>>>>>>>>>> built-in
>>>>>>>
>>>>>>>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller
>>>>>>>>>>>>>
>>>>>>>>>>>> (rev
>>>>>>>
>>>>>>>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
>>>>>>>>>>>>> Controller] (rev 03) -- and get the following message:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84"
>>>>>>>>>>>>>
>>>>>>>>>>>> "AC97a:83847600"
>>>>>>>
>>>>>>>> "0x1073" "0x000d"
>>>>>>>>>>>>> Hardware is initialized using a guess method
>>>>>>>>>>>>>
>>>>>>>>>>>>> As a consequence the volume levels of the Yamaha card do not
>>>>>>>>>>>>> get
>>>>>>>>>>>>> restored to the levels stored in /etc/asound.state.  The volume
>>>>>>>>>>>>>
>>>>>>>>>>>> levels
>>>>>>>
>>>>>>>> of the built-in card however are properly restored.  The
>>>>>>>>>>>>>
>>>>>>>>>>>> asound.state
>>>>>>>
>>>>>>>> file has been created by executing 'alsactl store'.
>>>>>>>>>>>>>
>>>>>>>>>>>>>  your problem is "alsactl restore" become "alsactl init" when
>>>>>> the number
>>>>>>
>>>>> of
>>>>>
>>>>>> controls is more than those in state file.
>>>>>>
>>>>> I'm not quite sure that the case is this since 'alsactl restore' does
>>>>> restore the values of the Yamaha sound card (and those of the other
>>>>> card, too) and 'alsactl restore 1' seems to just initialize the Yamaha
>>>>> card.  This is with alsa-utils version 1.0.22.
>>>>>
>>>>>  "Hardware is initialized using a guess method "  is the message used
>>>> by
>>>> alsactl init
>>>>
>>>>
>>>>
>>> http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=9a748178d1c9e783242f0cc794ab3efb27092f34;hp=0c02a4e3d23c7b5d03215f1bfaba9f70ed11e9b7
>>>
>>> I don't get what you mean. Could you explain a little bit more?
>>>
>>>  post the output of alsa-info.sh after  "alsactl init"
>>
>> and immeditate after the system boot
>>
>
> I'm sending the requested output as an attachment.
>
> Angel Tsankov
>

As you can see the driver has 79 controls but only 48 controls saved in the
asound.state

that is why "alsactl restore" become "alsactl init"


!!Amixer output
!!-------------

!!-------Mixer controls for card 0 [YMF724F]

Card hw:0 'YMF724F'/'Yamaha DS-1 (YMF724F) at 0xfb000000, irq 5'
  Mixer name    : 'SigmaTel STAC9700,83,84'
  Components    : 'AC97a:83847600'
  Controls      : 79
  Simple ctrls  : 31

Re: alsactl restore: unknown hardware: ymf724f

[Angel Tsankov]

Raymond Yau wrote:
> 2010/3/29 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
> 
>> Raymond Yau wrote:
>>
>>> 2010/3/29 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
>>>
>>>  Raymond Yau wrote:
>>>>> 2010/3/26 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
>>>>>
>>>>>  Hello again!
>>>>>> I've recently had some time to investigate this problem further on and
>>>>>> here's what I've discovered:
>>>>>>
>>>>>> Raymond Yau wrote:
>>>>>>
>>>>>>> 2010/2/26 Pacho Ramos <pacho@condmat1.ciencias.uniovi.es>
>>>>>>>
>>>>>>>  El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió:
>>>>>>>>> Raymond Yau wrote:
>>>>>>>>>
>>>>>>>>>> 2010/2/25 Jaroslav Kysela <perex@perex.cz>
>>>>>>>>>>
>>>>>>>>>>  On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>>>>>>>>  Jaroslav Kysela wrote:
>>>>>>>>>>>>> On Thu, 25 Feb 2010, Angel Tsankov wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>  Hello,
>>>>>>>>>>>>>> I run 'alsactl restore' on a machine with 2 sound cards -- a
>>>>>>>>>>>>>>
>>>>>>>>>>>>> built-in
>>>>>>>>> Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller
>>>>>>>>>>>>> (rev
>>>>>>>>> 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio
>>>>>>>>>>>>>> Controller] (rev 03) -- and get the following message:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84"
>>>>>>>>>>>>>>
>>>>>>>>>>>>> "AC97a:83847600"
>>>>>>>>> "0x1073" "0x000d"
>>>>>>>>>>>>>> Hardware is initialized using a guess method
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As a consequence the volume levels of the Yamaha card do not
>>>>>>>>>>>>>> get
>>>>>>>>>>>>>> restored to the levels stored in /etc/asound.state.  The volume
>>>>>>>>>>>>>>
>>>>>>>>>>>>> levels
>>>>>>>>> of the built-in card however are properly restored.  The
>>>>>>>>>>>>> asound.state
>>>>>>>>> file has been created by executing 'alsactl store'.
>>>>>>>>>>>>>>  your problem is "alsactl restore" become "alsactl init" when
>>>>>>> the number
>>>>>>>
>>>>>> of
>>>>>>
>>>>>>> controls is more than those in state file.
>>>>>>>
>>>>>> I'm not quite sure that the case is this since 'alsactl restore' does
>>>>>> restore the values of the Yamaha sound card (and those of the other
>>>>>> card, too) and 'alsactl restore 1' seems to just initialize the Yamaha
>>>>>> card.  This is with alsa-utils version 1.0.22.
>>>>>>
>>>>>>  "Hardware is initialized using a guess method "  is the message used
>>>>> by
>>>>> alsactl init
>>>>>
>>>>>
>>>>>
>>>> http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=9a748178d1c9e783242f0cc794ab3efb27092f34;hp=0c02a4e3d23c7b5d03215f1bfaba9f70ed11e9b7
>>>>
>>>> I don't get what you mean. Could you explain a little bit more?
>>>>
>>>>  post the output of alsa-info.sh after  "alsactl init"
>>> and immeditate after the system boot
>>>
>> I'm sending the requested output as an attachment.
> 
> As you can see the driver has 79 controls but only 48 controls saved in the
> asound.state
> 
> that is why "alsactl restore" become "alsactl init"
> 
> 
> !!Amixer output
> !!-------------
> 
> !!-------Mixer controls for card 0 [YMF724F]
> 
> Card hw:0 'YMF724F'/'Yamaha DS-1 (YMF724F) at 0xfb000000, irq 5'
>   Mixer name    : 'SigmaTel STAC9700,83,84'
>   Components    : 'AC97a:83847600'
>   Controls      : 79
>   Simple ctrls  : 31

My question was why 'alsactl restore' restores the sound card and 
'alsactl restore 1' just initializes the card.

Angel Tsankov

Re: alsactl restore: unknown hardware: ymf724f

[Raymond Yau]

2010/4/2 Angel Tsankov <fn42551@fmi.uni-sofia.bg>

> .
> >
> > As you can see the driver has 79 controls but only 48 controls saved in
> the
> > asound.state
> >
> > that is why "alsactl restore" become "alsactl init"
> >
> >
> > !!Amixer output
> > !!-------------
> >
> > !!-------Mixer controls for card 0 [YMF724F]
> >
> > Card hw:0 'YMF724F'/'Yamaha DS-1 (YMF724F) at 0xfb000000, irq 5'
> >   Mixer name    : 'SigmaTel STAC9700,83,84'
> >   Components    : 'AC97a:83847600'
> >   Controls      : 79
> >   Simple ctrls  : 31
>
> My question was why 'alsactl restore' restores the sound card and
> 'alsactl restore 1' just initializes the card.
>
> Angel Tsankov
>

you have to find out the value of doit

1443         /* check if we have additional controls in driver */
1444         /* in this case we should go through init procedure */
1445         if (!doit && maxnumid >= 0) {


http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=05f78cc6811110156c701fd9a2a5d15de8b4b1c7;hp=6232f1c96cde1fee247e95cd97235c48cc7b168d