Re: alsactl restore: unknown hardware: ymf724f

[Raymond Yau <superquad.vortex2@gmail.com>]

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


when driver contains more controls than state file. In this case,
initialization procedure should be run

http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=05f78cc6811110156c701fd9a2a5d15de8b4b1c7;hp=6232f1c96cde1fee247e95cd97235c48cc7b168d