What do the sound levels look like *before* the desktop is loaded?

How do I find that out?

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

Run alsamixer on a terminal, see what things are set at.

*** Bug 133598 has been marked as a duplicate of this bug. ***

I just rebooted and checked - Master is set to Off which it wasn't
before the reboot.

What happens if you manually run 'alsactl restore'?

Nothing. I still have to restore the settings manually

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. :)

The issue have been describe here :
http://www.redhat.com/archives/fedora-test-list/2004-September/msg01233.html

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

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

Patch coming.

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
"Unloading").
The "remove snd-XXXX { /usr/sbin/alsactl store ..." line in modprobe.conf works
fine.

The component should be set to udev.

Created attachment 104356 [details]
/etc/dev.d/sound/alsa.dev file

Check if /usr/sbin/alsactl is executable.

If we're going the dev.d route, we really should move alsa-lib and
alsactl to the root FS.

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.

*** Bug 133939 has been marked as a duplicate of this bug. ***

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?

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. :/

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?

Presumably this is on a udev-enabled system?

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

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)

Does the new alsa-utils and alsa-lib work for other people, or do they
see the same failure?

Doesn't restore volume levels here either, using a SB Live! 5.1 card
(emu10k1).

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:

udev-038-1
alsa-utils-1.0.6-2
alsa-lib-1.0.6-3

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.

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. 

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
one.)

ok here is my modified script:

#!/bin/sh
echo "$ACTION" >> /tmp/udev.dbg
if [ "$ACTION" = "add" ]; then
        echo "$DEVPATH" >> /tmp/udev.dbg
        card=`echo $DEVPATH | sed -n -e
"s/^\/class\/sound\/pcmC\([[:digit:]]\+\).*/\1/p"`
        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
        fi
fi

and here is the output I get:

add
/class/sound/pcmC0D0c
add
/class/sound/pcmC0D0p
add
/class/sound/midiC0D0
0
restoring...
0
restoring...

add
/class/sound/controlC0
add
/class/sound/timer
add
/class/sound/midi
add

/class/sound/dmmidi

add
/class/sound/dsp

add
/class/sound/audio

add
/class/sound/mixer

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.

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?

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

oh @(&#$()@#$ i just realized i used trace and not strace, stupid cut
& paste!  trying again...

Created attachment 105310 [details]
strace output 1

strace of first alsactl call

Created attachment 105311 [details]
strace output 2

strace output of second alsactl call

Created attachment 105312 [details]
strace output 3

strance of alsactl call by hand that works.

So, on *my* test box, /dev/snd/controlC0 gets created first, then
/dev/snd/pcmC0...

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

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

(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. :/

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

I do not understand the use of /class/sound/pcmC*

I trace alsa.dev :
#!/bin/sh
/usr/bin/logger -t $(basename $0)"[$$]" : $DEVPATH
if [ "$ACTION" = "add" ]; then
        card=`echo $DEVPATH | sed -n -e
"s/^\/class\/sound\/pcmC\([[:digit:]]\+\).*/\1/p"`
        if [ -n "$card" -a -x /sbin/alsactl ] ; then
                /usr/bin/logger -t $(basename $0)"[$$]" : $card :
`/sbin/alsactl restore $card 2>&1`
        fi
fi

Here is what I get :

Card 0 (snd-ens1371) :

/class/sound/midiC0D0
/class/sound/pcmC0D1p
0 : /sbin/alsactl: set_controls:986: snd_ctl_open error: No such file
or directory
/class/sound/pcmC0D0p
0 : /sbin/alsactl: set_controls:986: snd_ctl_open error: No such file
or directory
/class/sound/pcmC0D0c
0 : /sbin/alsactl: set_controls:986: snd_ctl_open error: No such file
or directory
/class/sound/controlC0
/class/sound/timer
/class/sound/dmmidi
/class/sound/midi
/class/sound/adsp
/class/sound/audio
/class/sound/mixer
/class/sound/dsp



Card 1 (snd-via82xx) :

/class/sound/pcmC1D1p
1 : /sbin/alsactl: set_controls:986: snd_ctl_open error: No such file
or directory
/class/sound/pcmC1D0p
/class/sound/pcmC1D1c
1 : /sbin/alsactl: set_controls:986: snd_ctl_open error: No such file
or directory
/class/sound/pcmC1D0c
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
/class/sound/controlC1
/class/sound/adsp1
/class/sound/dsp1
/class/sound/audio1
/class/sound/mixer1


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 :
http://www.redhat.com/archives/fedora-test-list/2004-October/msg00647.html

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
wait_for_sysfs.

Good news ! udev-038-1 and my previous patch (
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=104356&action=view
) work nicely :-)

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).

Created attachment 105321 [details]
/etc/dev.d/sound/alsa.dev file (use controlC*)

Cleanup.

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.

Why don't we use both cases? One of them is eventually bound to work.

That's probably what has to be done, but it certainly sets off the
ick-o-meter.

*** Bug 136071 has been marked as a duplicate of this bug. ***

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?

> does this work for people?

Works here with snd-ens1371 and snd-via82xx.

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
muted.

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)

Created attachment 105541 [details]
strace on boot

Created attachment 105542 [details]
strace after boot

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

The boot environment has no stdin/stdout/stderr. But it looks like it
succeeds... odd.

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.

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
fi


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


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

Created attachment 105546 [details]
/etc/rc.d/init.d/alsactl

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

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.

Yeah, if it's just failing in KDE, KDE is doing something odd. Please
file a new bug against that.

Closing as resolved.

For those who want to continue following this, the new bug is open at
bug #136543

*** Bug 137311 has been marked as a duplicate of this bug. ***