Re: alsactl restore: unknown hardware: ymf724f

[Raymond Yau <superquad.vortex2@gmail.com>]

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
    }