Re: alsactl restore: unknown hardware: ymf724f

[Angel Tsankov <fn42551@fmi.uni-sofia.bg>]

Angel Tsankov wrote:
> Raymond Yau wrote:
>> 2010/2/27 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
>>
>>> Raymond Yau wrote:
>>>
>>>> 2010/2/26 Angel Tsankov <fn42551@fmi.uni-sofia.bg>
>>>>
>>>>  Raymond Yau wrote:
>>>>>> 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
>>>>>>    }
>>>>>>
>>>>> 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