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