[alsa-devel] alsactl restore: unknown hardware: ymf724f
Raymond Yau
superquad.vortex2 at gmail.com
Sat Feb 27 12:21:38 CET 2010
2010/2/27 Angel Tsankov <fn42551 at fmi.uni-sofia.bg>
> Raymond Yau wrote:
> > 2010/2/27 Angel Tsankov <fn42551 at fmi.uni-sofia.bg>
> >
> >> Raymond Yau wrote:
> >>
> >>> 2010/2/26 Angel Tsankov <fn42551 at fmi.uni-sofia.bg>
> >>>
> >>> Raymond Yau wrote:
> >>>>> 2010/2/25 Jaroslav Kysela <perex at 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!
>
> 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...
>
>
> Regards,
> Angel Tsankov
> <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>
>
I guess that the purpose of that patch is used for those Live CD which did
not has asound.state , therefore sound will initialised to an audible volume
by using alsactl restore
When the driver has more controls than asound.state ( no controls in asound
state)
if there is no sound playing when system shut down , the control will not
be saved
However if there is system event sound playing or an application open the
sound card while alsactl restore from asound.state ( ymfpci and via82xx
will have one controls more than the state file , alsactl restore will
initialised to to an audible volume instead of restore the values from
asound.state
> l <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>
>
More information about the Alsa-devel
mailing list