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