[alsa-devel] alsactl restore: unknown hardware: ymf724f

[Raymond Yau]

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

> Raymond Yau wrote:
> > 2010/2/25 Jaroslav Kysela <perex at 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