Bug 133535 - Sound settings not restored on startup
Summary: Sound settings not restored on startup
Alias: None
Product: Fedora
Classification: Fedora
Component: alsa-utils
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
: 133598 133939 136071 137311 (view as bug list)
Depends On:
Blocks: FC3Target
TreeView+ depends on / blocked
Reported: 2004-09-24 17:39 UTC by Paul F. Johnson
Modified: 2014-03-17 02:48 UTC (History)
12 users (show)

Fixed In Version: 1.0.6-3
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-10-20 20:39:00 UTC

Attachments (Terms of Use)
/etc/dev.d/sound/alsa.dev file (219 bytes, text/plain)
2004-09-27 07:08 UTC, Féliciano Matias
no flags Details
/etc/dev.d/sound/alsa.dev file (246 bytes, patch)
2004-09-27 08:28 UTC, Féliciano Matias
no flags Details | Diff
strace output 1 (8.23 KB, text/plain)
2004-10-15 22:31 UTC, Christopher Stone
no flags Details
strace output 2 (8.23 KB, text/plain)
2004-10-15 22:32 UTC, Christopher Stone
no flags Details
strace output 3 (8.72 KB, text/plain)
2004-10-15 22:33 UTC, Christopher Stone
no flags Details
/etc/dev.d/sound/alsa.dev file (use controlC*) (244 bytes, text/plain)
2004-10-16 08:19 UTC, Féliciano Matias
no flags Details
/etc/dev.d/sound/alsa.dev file (use controlC*) (229 bytes, text/plain)
2004-10-16 08:28 UTC, Féliciano Matias
no flags Details
new script (238 bytes, text/plain)
2004-10-20 03:25 UTC, Bill Nottingham
no flags Details
strace on boot (10.85 KB, text/plain)
2004-10-20 19:12 UTC, Christopher Stone
no flags Details
strace after boot (8.72 KB, text/plain)
2004-10-20 19:14 UTC, Christopher Stone
no flags Details
/etc/rc.d/init.d/alsactl (1.37 KB, text/plain)
2004-10-20 20:17 UTC, Féliciano Matias
no flags Details

Description Paul F. Johnson 2004-09-24 17:39:08 UTC
Description of problem:
When I shut down and restart my machine, I have to either re-run
system-config-soundcard or use gnome-volumecontrol to unmute/reenable
my sound card levels

Version-Release number of selected component (if applicable):
1.0.6-1 (both alsa-lib and alsa-utils)

How reproducible:

Steps to Reproduce:
1. Shut down and restart
Actual results:
Sound levels reset to muted on all devices

Expected results:
Sound levels should be the same as when the desktop was left

Additional info:

Comment 1 Bill Nottingham 2004-09-24 18:36:08 UTC
What do the sound levels look like *before* the desktop is loaded?

Comment 2 Paul F. Johnson 2004-09-24 21:17:52 UTC
How do I find that out?

I know if I log in a terminal, I cannot hear anything from the CD player.

Comment 3 Bill Nottingham 2004-09-24 22:25:50 UTC
Run alsamixer on a terminal, see what things are set at.

Comment 4 Bill Nottingham 2004-09-25 00:37:55 UTC
*** Bug 133598 has been marked as a duplicate of this bug. ***

Comment 5 David Nielsen 2004-09-25 00:45:31 UTC
I just rebooted and checked - Master is set to Off which it wasn't
before the reboot.

Comment 6 Bill Nottingham 2004-09-25 06:22:32 UTC
What happens if you manually run 'alsactl restore'?

Comment 7 Paul F. Johnson 2004-09-25 09:35:28 UTC
Nothing. I still have to restore the settings manually

Comment 8 raxet 2004-09-25 17:57:07 UTC
After doing an alsactl store and then placing alsactl restore in the
rc.local and I don't have to manually restore from soundcard detect or
volume-control after reboot. Works for me like it used to Fedora Cores
before. :)

Comment 9 Féliciano Matias 2004-09-27 07:04:42 UTC
The issue have been describe here :

Bill Nottingham suggested to use /etc/dev.d .

Note that "install snd-XXXX /sbin/modprobe ..." lines in modprobe are

Patch coming.

Comment 10 Féliciano Matias 2004-09-27 07:08:41 UTC
Created attachment 104355 [details]
/etc/dev.d/sound/alsa.dev file

Note that we can't use /etc/dev.d/ to store sound setting (modules marked
The "remove snd-XXXX { /usr/sbin/alsactl store ..." line in modprobe.conf works

Comment 11 Féliciano Matias 2004-09-27 07:13:41 UTC
The component should be set to udev.

Comment 12 Féliciano Matias 2004-09-27 08:28:21 UTC
Created attachment 104356 [details]
/etc/dev.d/sound/alsa.dev file

Check if /usr/sbin/alsactl is executable.

Comment 13 Bill Nottingham 2004-09-27 15:56:54 UTC
If we're going the dev.d route, we really should move alsa-lib and
alsactl to the root FS.

Comment 14 Féliciano Matias 2004-09-27 17:44:34 UTC
I think audio, tv, nvidea, etc... should be loaded (modprobe) after
all local filesystems (think /usr) are mounted.

I don't see why we had to modprobe "misc" modules very early at boot time.

This should be done in a service like named ou httpd. Launched after
kudzu service.

Comment 15 Bill Nottingham 2004-09-29 04:48:01 UTC
*** Bug 133939 has been marked as a duplicate of this bug. ***

Comment 16 Richard Hughes 2004-10-01 06:37:46 UTC
My systems is updated to rawhide. I've had to manually unmute my
volume every time I start my laptop for the last couple of weeks. The
file proposed by Féliciano Matias in Comment #12 works for me - my
ALSA volumes are no longer muted or set to 0. Is this not a blocker
for FC3?

Comment 17 Bill Nottingham 2004-10-14 21:51:29 UTC
Fixed in alsa-utils-1.0.6-2. Note that the script has to operate on
/dev/snd/pcmXXX; /dev/snd/controlXX is available before the actual
mixer is. :/

Comment 18 Christopher Stone 2004-10-15 18:09:20 UTC
Hello.  I just tested a reboot using alsa-utils-1.0.6-2, and my volume
is still being reset to zero.  I still need to type alsactl restore in
order to get my volume back.  Anything I'm doing wrong, or missing?

Comment 19 Bill Nottingham 2004-10-15 19:06:06 UTC
Presumably this is on a udev-enabled system?

a) do you have a separate /usr?
b) what sort of card?

Comment 20 Christopher Stone 2004-10-15 19:17:26 UTC
Bill, I am running FC3T3 with yum updates installed.  I don't have a
seperate /usr.  lspci says I have:

02:0c.0 Multimedia audio controller: ESS Technology ES1978 Maestro 2E
(rev 10)

Comment 21 Bill Nottingham 2004-10-15 20:10:24 UTC
Does the new alsa-utils and alsa-lib work for other people, or do they
see the same failure?

Comment 22 David Nielsen 2004-10-15 21:03:16 UTC
Doesn't restore volume levels here either, using a SB Live! 5.1 card

Comment 23 Christopher Stone 2004-10-15 21:07:41 UTC
How can I debug this?  I tried to put echo lines in
/etc/dev.d/sound/alsa.dev but I did not see any of my echo statements
being printed on boot.   I can't even tell if this file is being
executed.  What should $DEVPATH be equal to? Can I test to see if the
sed statement works for my configuration?  Where does my volume
settings get stored when I shutdown? I had an /etc/asound.state file
from when I ran alsactl store before, should I remove this file?  I am
currently running:


Comment 24 Bill Nottingham 2004-10-15 21:13:14 UTC
1) it's executed without a tty. Debugging echos (or whatever) would
need to be dumped to a file in /tmp or similar
2) DEVPATH is the name of the path in /sys that is triggering the udev
event... /sys/class/sound/pcmC0D0c, for example.
3) volume settings are stored in /etc/asound.state on shutdown
4) no, you shouldn't remove it (although, you may want to check to see
if it's *storing* zero/muted volume.

Comment 25 Christopher Stone 2004-10-15 21:28:08 UTC
okay, I put in the debug statements and sent them to a file in /tmp,
and here is what I found out:

DEVPATH is equal to /class/sound/mixer and therefore the sed statement
in alsa.dev fails. 

Comment 26 Bill Nottingham 2004-10-15 21:36:02 UTC
That's the only one you get? (There should be about 10 or twelve udev
invocations... if you do '>' instead of '>>' you'll only get the last

Comment 27 Christopher Stone 2004-10-15 21:53:49 UTC
ok here is my modified script:

echo "$ACTION" >> /tmp/udev.dbg
if [ "$ACTION" = "add" ]; then
        echo "$DEVPATH" >> /tmp/udev.dbg
        card=`echo $DEVPATH | sed -n -e
        echo "$card" >> /tmp/udev.dbg
        if [ -n "$card" -a -x /sbin/alsactl ] ; then
                echo "restoring..." >> /tmp/udev.dbg
                /sbin/alsactl restore $card > /dev/null 2>&1

and here is the output I get:







So it appears it's trying to restore the volume twice, I guess the
output file is not necessarily in the correct order.  My guess is that
its calling alsactl restore on both the pcmC0D0c and pcmC0D0p.

When I boot into KDE though, the volume is set to zero, and if I issue
the command alsactl restore 0 by hand, the volume gets reset correctly.

Comment 28 Bill Nottingham 2004-10-15 22:07:32 UTC
Hm, just to make sure, it's also set at 0 before you run kde?

Could you change it to strace -o /tmp/alsactl.$$ /sbin/alsactl restore ...

and post the output?

Comment 29 Christopher Stone 2004-10-15 22:21:37 UTC
I changed the script to use:
trace -o /tmp/alsactl.$$ /sbin/alsactl restore $card > /dev/null 2>&1

and while my /tmp/udev.dbg file shows it calling restore twice, there
were no /tmp/alsactl.* files:

# ls /tmp/al*
ls: /tmp/al*: No such file or directory

Comment 30 Christopher Stone 2004-10-15 22:22:42 UTC
oh @(&#$()@#$ i just realized i used trace and not strace, stupid cut
& paste!  trying again...

Comment 31 Christopher Stone 2004-10-15 22:31:45 UTC
Created attachment 105310 [details]
strace output 1

strace of first alsactl call

Comment 32 Christopher Stone 2004-10-15 22:32:39 UTC
Created attachment 105311 [details]
strace output 2

strace output of second alsactl call

Comment 33 Christopher Stone 2004-10-15 22:33:31 UTC
Created attachment 105312 [details]
strace output 3

strance of alsactl call by hand that works.

Comment 34 Bill Nottingham 2004-10-16 03:05:34 UTC
So, on *my* test box, /dev/snd/controlC0 gets created first, then

We trigger on /dev/snd/pcmC0... and the restore works.

On your box, /dev/snd/pcmC0 gets created first, and /dev/snd/controlC0

(Instead of an strace, before the call to alsactl, can you just do 'ls
-l /dev/snd > /tmp/foo.$$ (or whatever), to verify this?)

I think I'm going to go shoot myself now. Or the udev maintainer. :/

Comment 35 Christopher Stone 2004-10-16 03:15:42 UTC
Well, they all have the same date, so I did ls -lt to order by time
where the oldest files are listed last:

$ ls -lt /dev/snd
total 0
crw-------  1 chris root 116,  1 Oct 15 15:59 seq
crw-------  1 chris root 116, 33 Oct 15 15:29 timer
crw-------  1 chris root 116,  0 Oct 15 15:29 controlC0
crw-------  1 chris root 116, 16 Oct 15 15:29 pcmC0D0p
crw-------  1 chris root 116, 24 Oct 15 15:29 pcmC0D0c
crw-------  1 chris root 116,  8 Oct 15 15:29 midiC0D0

Comment 36 Féliciano Matias 2004-10-16 08:07:40 UTC
I do not understand the use of /class/sound/pcmC*

I trace alsa.dev :
/usr/bin/logger -t $(basename $0)"[$$]" : $DEVPATH
if [ "$ACTION" = "add" ]; then
        card=`echo $DEVPATH | sed -n -e
        if [ -n "$card" -a -x /sbin/alsactl ] ; then
                /usr/bin/logger -t $(basename $0)"[$$]" : $card :
`/sbin/alsactl restore $card 2>&1`

Here is what I get :

Card 0 (snd-ens1371) :

0 : /sbin/alsactl: set_controls:986: snd_ctl_open error: No such file
or directory
0 : /sbin/alsactl: set_controls:986: snd_ctl_open error: No such file
or directory
0 : /sbin/alsactl: set_controls:986: snd_ctl_open error: No such file
or directory

Card 1 (snd-via82xx) :

1 : /sbin/alsactl: set_controls:986: snd_ctl_open error: No such file
or directory
1 : /sbin/alsactl: set_controls:986: snd_ctl_open error: No such file
or directory
1 : /sbin/alsactl: set_controls:986: snd_ctl_open error: No such file
or directory
1 : /sbin/alsactl: set_controls:986: snd_ctl_open error: No such file
or directory

alsactl is called 3 times for the first card and 4 times for the
second card.
pcmC* is brought before controlC* but alsactl only use controlC* .
When pcmC* are created, controlC* do not exist ("No such file or
directory" error message)

If alsa.dev use controlC* there is another problem described (as I
understand) here :

This "bug" append with udev >= 034. I got "No such device". It's
different than "No such file or directory".
I proposed a ugly workaround.

Harald Hoyer said the problem is perhaps related to the new

Good news ! udev-038-1 and my previous patch (
) work nicely :-)

Comment 37 Féliciano Matias 2004-10-16 08:19:13 UTC
Created attachment 105320 [details]
/etc/dev.d/sound/alsa.dev file (use controlC*)

cleanup and update to use /sbin/alsactl (alsa-utils-1.0.6-2).

Comment 38 Féliciano Matias 2004-10-16 08:28:18 UTC
Created attachment 105321 [details]
/etc/dev.d/sound/alsa.dev file (use controlC*)


Comment 39 Bill Nottingham 2004-10-17 03:43:41 UTC
Ahh... except with some sound drivers, controlC0 is registered first..
before there is any hardware device available.

So that won't work either.

Basically, ALSA is pretty broken.

Comment 40 Christopher Stone 2004-10-17 04:00:58 UTC
Why don't we use both cases? One of them is eventually bound to work.

Comment 41 Bill Nottingham 2004-10-17 04:11:44 UTC
That's probably what has to be done, but it certainly sets off the

Comment 42 Bill Nottingham 2004-10-18 03:13:54 UTC
*** Bug 136071 has been marked as a duplicate of this bug. ***

Comment 43 Bill Nottingham 2004-10-20 03:25:21 UTC
Created attachment 105491 [details]
new script

This is what's going to be in alsa-utils-1.0.6-3 - does this work for people?

Comment 44 Féliciano Matias 2004-10-20 08:53:16 UTC
> does this work for people?

Works here with snd-ens1371 and snd-via82xx.

Comment 45 Rodd Clarkson 2004-10-20 10:17:21 UTC
Didn't work for me.

I've got a 00:08.0 Multimedia audio controller: ESS Technology ES1978
Maestro 2E (rev 10)

All the volumes are at 0 (no volume) and most of the volumes are muted.

On shutdown, the PCM and CD volumes were at about 80% and both weren't

Comment 46 Christopher Stone 2004-10-20 19:06:02 UTC
Still doesn't work for me either.  I did an strace on the alsactl call
and it looks okay to me.  Still need to run alsactl by hand after boot
for it to work.

My sound card is a ESS Technology ES1978 Maestro 2E (rev 10)

Comment 47 Christopher Stone 2004-10-20 19:12:47 UTC
Created attachment 105541 [details]
strace on boot

Comment 48 Christopher Stone 2004-10-20 19:14:13 UTC
Created attachment 105542 [details]
strace after boot

Notice the strace after boot uses ioctl(3,...) and the one during boot uses

Comment 49 Bill Nottingham 2004-10-20 19:23:04 UTC
The boot environment has no stdin/stdout/stderr. But it looks like it
succeeds... odd.

Comment 50 Christopher Stone 2004-10-20 20:05:50 UTC
I did some more testing.  Booting into runlevel 3, the sound is
restored properly.  Logging into GNOME, the sound is restored
properly.  Logging into KDE, the sound is reset to zero.

Comment 51 Féliciano Matias 2004-10-20 20:16:04 UTC
Time for an ugly solution ? OK, I do it :-)

As alsa did some time ago, perhaps we should use /etc/rc.d/init.d/alsactl.
It's just for the record.

alsa-utils.spec :

postinstall scriptlet (using /bin/sh):
/sbin/chkconfig --add alsactl
/sbin/chkconfig alsactl on

preuninstall scriptlet (using /bin/sh):
if [ $1 = 0 ]; then
   /sbin/chkconfig --del alsactl
   /sbin/service alsactl condstop >/dev/null 2>&1

postuninstall scriptlet (using /bin/sh):
if [ "$1" -ge 1 ]; then
    /sbin/service alsactl condrestart >/dev/null 2>&1 || :

Not tested.
/etc/rc.d/init.d/alsactl coming.

Comment 52 Féliciano Matias 2004-10-20 20:17:50 UTC
Created attachment 105546 [details]

A proposition to use /etc/rc.d/init.d/alsactl as a workaround.

Comment 53 Christopher Stone 2004-10-20 20:29:04 UTC
I think it's working properly, I think it's KDE's fault that the sound
is resetting now, as it works in runlevel 3 and in GNOME.

Comment 54 Bill Nottingham 2004-10-20 20:39:00 UTC
Yeah, if it's just failing in KDE, KDE is doing something odd. Please
file a new bug against that.

Closing as resolved.

Comment 55 Christopher Stone 2004-10-20 20:47:29 UTC
For those who want to continue following this, the new bug is open at
bug #136543

Comment 56 Bill Nottingham 2004-10-27 16:16:15 UTC
*** Bug 137311 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.