2010/2/26 Angel Tsankov <fn42551@xxxxxxxxxxxxxxxx> > Raymond Yau wrote: > > 2010/2/25 Jaroslav Kysela <perex@xxxxxxxx> > > > >> 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
