[alsa-devel] alsactl restore: unknown hardware: ymf724f
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?
Regards, Angel Tsankov
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.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
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.
Jaroslav
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.
Regards, Angel Tsankov
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
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
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 }
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, Jaroslavdid 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
El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió:
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.
Looks similar to my problem: http://www.spinics.net/lists/alsa-devel/msg31422.html
Pacho Ramos wrote:
El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió:
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.
Looks similar to my problem: http://www.spinics.net/lists/alsa-devel/msg31422.html
Most interestingly, my exit status is the same -- 157. I thought it was 99.
Regards, Angel Tsankov
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, Jaroslavdid 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
2010/2/26 Pacho Ramos pacho@condmat1.ciencias.uniovi.es
El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió:
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.
Looks similar to my problem: http://www.spinics.net/lists/alsa-devel/msg31422.html
what is the content of your asound.state ?
seem related to this patch if alsactl count those iface_pcm controls
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=05f78cc68111101...
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, Jaroslavdid 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
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, Jaroslavdid 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:
- I removed /etc/asound.state (just in case);
- 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=05f78cc68111101...
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, Jaroslavdid 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:
- I removed /etc/asound.state (just in case);
- 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
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:
- I removed /etc/asound.state (just in case);
- 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
2010/2/27 Angel Tsankov fn42551@fmi.uni-sofia.bg
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:
- I removed /etc/asound.state (just in case);
- 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
2010/2/27 Angel Tsankov fn42551@fmi.uni-sofia.bg
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.
Regards, Angel Tsankov
That is the per voice volume control which use the hardware mixer in ymf754 chip instead of the mixer of ac97 codec
ymf754 has 32 playback subdevices , each subdevices has one hardware mixer volume control
the values are set to 0dB by the driver when the subdevice is open , DSP can mix 32 streams by hardware
when the driver is loaded there are 32 controls which are inactive and the total number of controls should more that those controls in asound.state since those iface PCM "PCM playback volume controls" are not saved at shutdown because all 32 controls are inactive when 32 subdevices are closed
Raymond Yau wrote:
2010/2/27 Angel Tsankov fn42551@fmi.uni-sofia.bg
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.
Regards, Angel Tsankov
That is the per voice volume control which use the hardware mixer in ymf754
The device in question is YMF724F.
chip instead of the mixer of ac97 codec
ymf754 has 32 playback subdevices , each subdevices has one hardware mixer volume control
the values are set to 0dB by the driver when the subdevice is open , DSP can mix 32 streams by hardware
when the driver is loaded there are 32 controls which are inactive and the total number of controls should more that those controls in asound.state since those iface PCM "PCM playback volume controls" are not saved at shutdown because all 32 controls are inactive when 32 subdevices are closed
Angel Tsankov
Angel Tsankov wrote:
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:
- I removed /etc/asound.state (just in case);
- 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
2010/2/26 Pacho Ramos pacho@condmat1.ciencias.uniovi.es
El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió:
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.
Looks similar to my problem: http://www.spinics.net/lists/alsa-devel/msg31422.html
your problem is "alsactl restore" become "alsactl init" when the number of controls is more than those in state file.
"Hardware is initialized using a guess method" instead of restore from asound.state
alsactl -f /var/lib/alsa/asound.state restore Unknown hardware: "VIA8237" "Realtek ALC658D" "AC97a:414c4781" "0x147b" "0x1415" Hardware is initialized using a guess method
Hello again!
I've recently had some time to investigate this problem further on and here's what I've discovered:
Raymond Yau wrote:
2010/2/26 Pacho Ramos pacho@condmat1.ciencias.uniovi.es
El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió:
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.
Looks similar to my problem: http://www.spinics.net/lists/alsa-devel/msg31422.html
your problem is "alsactl restore" become "alsactl init" when the number of controls is more than those in state file.
I'm not quite sure that the case is this since 'alsactl restore' does restore the values of the Yamaha sound card (and those of the other card, too) and 'alsactl restore 1' seems to just initialize the Yamaha card. This is with alsa-utils version 1.0.22.
Regards,
Angel Tsankov
2010/3/26 Angel Tsankov fn42551@fmi.uni-sofia.bg
Hello again!
I've recently had some time to investigate this problem further on and here's what I've discovered:
Raymond Yau wrote:
2010/2/26 Pacho Ramos pacho@condmat1.ciencias.uniovi.es
El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió:
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'. >>>
your problem is "alsactl restore" become "alsactl init" when the number
of
controls is more than those in state file.
I'm not quite sure that the case is this since 'alsactl restore' does restore the values of the Yamaha sound card (and those of the other card, too) and 'alsactl restore 1' seems to just initialize the Yamaha card. This is with alsa-utils version 1.0.22.
Regards,
Angel Tsankov
"Hardware is initialized using a guess method " is the message used by alsactl init
http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=9a748178d1c9e78...
Raymond Yau wrote:
2010/3/26 Angel Tsankov fn42551@fmi.uni-sofia.bg
Hello again!
I've recently had some time to investigate this problem further on and here's what I've discovered:
Raymond Yau wrote:
2010/2/26 Pacho Ramos pacho@condmat1.ciencias.uniovi.es
El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió:
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'. >>>>
your problem is "alsactl restore" become "alsactl init" when the number
of
controls is more than those in state file.
I'm not quite sure that the case is this since 'alsactl restore' does restore the values of the Yamaha sound card (and those of the other card, too) and 'alsactl restore 1' seems to just initialize the Yamaha card. This is with alsa-utils version 1.0.22.
"Hardware is initialized using a guess method " is the message used by alsactl init
http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=9a748178d1c9e78...
I don't get what you mean. Could you explain a little bit more?
Regards, Angel Tsankov
2010/3/29 Angel Tsankov fn42551@fmi.uni-sofia.bg
Raymond Yau wrote:
2010/3/26 Angel Tsankov fn42551@fmi.uni-sofia.bg
Hello again!
I've recently had some time to investigate this problem further on and here's what I've discovered:
Raymond Yau wrote:
2010/2/26 Pacho Ramos pacho@condmat1.ciencias.uniovi.es
El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió:
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'. >>>>>
your problem is "alsactl restore" become "alsactl init" when the number
of
controls is more than those in state file.
I'm not quite sure that the case is this since 'alsactl restore' does restore the values of the Yamaha sound card (and those of the other card, too) and 'alsactl restore 1' seems to just initialize the Yamaha card. This is with alsa-utils version 1.0.22.
"Hardware is initialized using a guess method " is the message used by alsactl init
http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=9a748178d1c9e78...
I don't get what you mean. Could you explain a little bit more?
Regards, Angel Tsankov
post the output of alsa-info.sh after "alsactl init"
and immeditate after the system boot
Raymond Yau wrote:
2010/3/29 Angel Tsankov fn42551@fmi.uni-sofia.bg
Raymond Yau wrote:
2010/3/26 Angel Tsankov fn42551@fmi.uni-sofia.bg
Hello again!
I've recently had some time to investigate this problem further on and here's what I've discovered:
Raymond Yau wrote:
2010/2/26 Pacho Ramos pacho@condmat1.ciencias.uniovi.es
El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió: > 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'. >>>>>>
your problem is "alsactl restore" become "alsactl init" when the number
of
controls is more than those in state file.
I'm not quite sure that the case is this since 'alsactl restore' does restore the values of the Yamaha sound card (and those of the other card, too) and 'alsactl restore 1' seems to just initialize the Yamaha card. This is with alsa-utils version 1.0.22.
"Hardware is initialized using a guess method " is the message used by alsactl init
http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=9a748178d1c9e78...
I don't get what you mean. Could you explain a little bit more?
post the output of alsa-info.sh after "alsactl init"
and immeditate after the system boot
I'm sending the requested output as an attachment.
Angel Tsankov
2010/3/29 Angel Tsankov fn42551@fmi.uni-sofia.bg
Raymond Yau wrote:
2010/3/29 Angel Tsankov fn42551@fmi.uni-sofia.bg
Raymond Yau wrote:
2010/3/26 Angel Tsankov fn42551@fmi.uni-sofia.bg
Hello again!
I've recently had some time to investigate this problem further on and here's what I've discovered:
Raymond Yau wrote:
2010/2/26 Pacho Ramos pacho@condmat1.ciencias.uniovi.es
El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió: > >> 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'. >>>>>>> >>>>>>> your problem is "alsactl restore" become "alsactl init" when the number
of
controls is more than those in state file.
I'm not quite sure that the case is this since 'alsactl restore' does restore the values of the Yamaha sound card (and those of the other card, too) and 'alsactl restore 1' seems to just initialize the Yamaha card. This is with alsa-utils version 1.0.22.
"Hardware is initialized using a guess method " is the message used
by alsactl init
http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=9a748178d1c9e78...
I don't get what you mean. Could you explain a little bit more?
post the output of alsa-info.sh after "alsactl init"
and immeditate after the system boot
I'm sending the requested output as an attachment.
Angel Tsankov
As you can see the driver has 79 controls but only 48 controls saved in the asound.state
that is why "alsactl restore" become "alsactl init"
!!Amixer output !!-------------
!!-------Mixer controls for card 0 [YMF724F]
Card hw:0 'YMF724F'/'Yamaha DS-1 (YMF724F) at 0xfb000000, irq 5' Mixer name : 'SigmaTel STAC9700,83,84' Components : 'AC97a:83847600' Controls : 79 Simple ctrls : 31
Raymond Yau wrote:
2010/3/29 Angel Tsankov fn42551@fmi.uni-sofia.bg
Raymond Yau wrote:
2010/3/29 Angel Tsankov fn42551@fmi.uni-sofia.bg
Raymond Yau wrote:
2010/3/26 Angel Tsankov fn42551@fmi.uni-sofia.bg
Hello again!
I've recently had some time to investigate this problem further on and here's what I've discovered:
Raymond Yau wrote:
> 2010/2/26 Pacho Ramos pacho@condmat1.ciencias.uniovi.es > > El vie, 26-02-2010 a las 13:57 +0200, Angel Tsankov escribió: >>> 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'. >>>>>>>> your problem is "alsactl restore" become "alsactl init" when > the number > of
> controls is more than those in state file. > I'm not quite sure that the case is this since 'alsactl restore' does restore the values of the Yamaha sound card (and those of the other card, too) and 'alsactl restore 1' seems to just initialize the Yamaha card. This is with alsa-utils version 1.0.22.
"Hardware is initialized using a guess method " is the message used
by alsactl init
http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=9a748178d1c9e78...
I don't get what you mean. Could you explain a little bit more?
post the output of alsa-info.sh after "alsactl init"
and immeditate after the system boot
I'm sending the requested output as an attachment.
As you can see the driver has 79 controls but only 48 controls saved in the asound.state
that is why "alsactl restore" become "alsactl init"
!!Amixer output !!-------------
!!-------Mixer controls for card 0 [YMF724F]
Card hw:0 'YMF724F'/'Yamaha DS-1 (YMF724F) at 0xfb000000, irq 5' Mixer name : 'SigmaTel STAC9700,83,84' Components : 'AC97a:83847600' Controls : 79 Simple ctrls : 31
My question was why 'alsactl restore' restores the sound card and 'alsactl restore 1' just initializes the card.
Angel Tsankov
2010/4/2 Angel Tsankov fn42551@fmi.uni-sofia.bg
.
As you can see the driver has 79 controls but only 48 controls saved in
the
asound.state
that is why "alsactl restore" become "alsactl init"
!!Amixer output !!-------------
!!-------Mixer controls for card 0 [YMF724F]
Card hw:0 'YMF724F'/'Yamaha DS-1 (YMF724F) at 0xfb000000, irq 5' Mixer name : 'SigmaTel STAC9700,83,84' Components : 'AC97a:83847600' Controls : 79 Simple ctrls : 31
My question was why 'alsactl restore' restores the sound card and 'alsactl restore 1' just initializes the card.
Angel Tsankov
you have to find out the value of doit
1443 /* check if we have additional controls in driver */ 1444 /* in this case we should go through init procedure */ 1445 if (!doit && maxnumid >= 0) {
http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=05f78cc68111101...
participants (4)
-
Angel Tsankov -
Jaroslav Kysela -
Pacho Ramos -
Raymond Yau