Bug 126212 - (alsa-mute) default volume of zero makes no sense
default volume of zero makes no sense
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
: 119400 120602 121941 122068 122549 123964 (view as bug list)
Depends On:
Blocks: 126068
  Show dependency treegraph
Reported: 2004-06-17 12:10 EDT by Brent Fox
Modified: 2015-01-04 17:07 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-16 00:38:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
alsa /etc/rc.d/init.d script (5.56 KB, text/plain)
2004-07-11 15:31 EDT, Greg Morgan
no flags Details
Changed app to save aumix and alsa mixer setting on press of ok (12.58 KB, text/plain)
2004-07-17 13:55 EDT, Greg Morgan
no flags Details
Added a saveVolume method cloned from setVolume use with 102002 (9.99 KB, text/plain)
2004-07-17 14:00 EDT, Greg Morgan
no flags Details

  None (edit)
Description Brent Fox 2004-06-17 12:10:10 EDT
By default, ALSA sets the audio volume level to zero.  On fresh
installs, the soundcard screen in firstboot tries to set this to
something sane (60%-70%) or so.  However, it shouldn't be firstboot's
job to fix what is essentially a bad default setting.  We should
change the default setting to something audible.

The problem is most evident on upgrades.  Migrating from an oss sound
subsystem to an ALSA sound subsystem also causes the sound volume to
be reset to zero.  Since firstboot does not run on upgrades, there is
nothing to override the bad default.  Many bugs are mistakenly filed
against system-config-soundcard because the users believe that
something is wrong with either the soundcard driver or the
configuration when the real problem is a bad default setting.

I will cross link this bug report with the Featurezilla entry and then
dupe all the related system-config-soundcard bugs to this one.
Comment 1 Brent Fox 2004-06-17 12:11:48 EDT
*** Bug 123964 has been marked as a duplicate of this bug. ***
Comment 2 Brent Fox 2004-06-17 12:13:29 EDT
*** Bug 119400 has been marked as a duplicate of this bug. ***
Comment 3 Brent Fox 2004-06-17 12:20:22 EDT
*** Bug 122068 has been marked as a duplicate of this bug. ***
Comment 4 Brent Fox 2004-06-17 12:21:28 EDT
*** Bug 120602 has been marked as a duplicate of this bug. ***
Comment 5 Brent Fox 2004-06-17 14:16:34 EDT
*** Bug 122549 has been marked as a duplicate of this bug. ***
Comment 6 Mikel Ward 2004-06-17 18:42:50 EDT
I don't think this bug accurately describes many of the bugs marked as
duplicates of it.

In my situation, and certainly at least bug 122068 and bug 12254,
there was the initial problem that the defaults were zero after
upgrading, however the problem mentioned there is that the PCM volume
is muted after each reboot.

I thought there was supposed to be something in either the initscripts
or modprobe.conf to save the mixer levels on shutdown/unloading the
module and load the mixer levels on startup/loading the module.  If
there is, it would seem to be not working for people experiencing this

For what it's worth, I have an /etc/.aumixrc.  It is referred to in
/etc/modules.conf (Linux 2.4), but not /etc/modprobe.conf{,.dist}
(Linux 2.6) or any script in /etc/init.d as far as I can see.
Comment 7 Brent Fox 2004-06-23 15:49:57 EDT
*** Bug 121941 has been marked as a duplicate of this bug. ***
Comment 8 Bill Nottingham 2004-06-29 00:38:46 EDT
This is a driver level issue.

*** This bug has been marked as a duplicate of 115932 ***
Comment 9 Brent Fox 2004-06-29 11:22:32 EDT
notting: From looking at bug 115932, I can't tell if the default
volume will be non-zero in the future.  I think that the volume should
be non-zero without ever having to run system-config-soundcard.  I'm
not even sure that system-config-soundcard serves any useful purpose.
Comment 10 Bill Nottingham 2004-06-29 14:34:25 EDT
Assigning to the kernel then... the default sound volume of 0 is set
at the driver core level, much as the default sound volume of 50 was
set in the drivers under the OSS model.
Comment 11 Greg Morgan 2004-07-11 15:29:41 EDT
I would say part of the problem is that FC2 does not properly
transition to the ALSA sound system from the OSS system used in 2.4.x
kernels. I don't think the problem is related to the kernel. I
normally perform a clean install.  However, for FC1 to FC2 I performed
an upgrade.  I used the the gnome GStreamer-based mixer 2.6.0
application to set the sound levels.  I could not figure out why the
settings were not saved.  So I did some reading on the mail FC mailing
list, hunting, and experimenting.

So here's what I found.  I greped in /etc/rc.d/init.d for ALSA.  I
found that the halt command properly saves my ALSA mixer settings but
that was it. Here's the grep output:
halt:grep -q "\(alsa\)" /proc/devices
halt:if [ $? = 0 -a -x /usr/sbin/alsactl ]; then
halt:   runcmd $"Saving mixer settings" alsactl store
I could not find a place where the init scripts loaded my saved
settings. At some point my searches directed me the the /etc module
config files.  Here's where I began to understand what happened. 
Either the upgrade said no touching config files or as noted above
first boot applications pointlessly play a test sound without cleaning
out the legacy amixer settings or anaconda does note handle the OSS to
ALSA transitions properly.  In my upgraded FC2 system I found this
alias sound-slot-0 i810_audio
post-install sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -L
>/dev/null 2>&1 || :
pre-remove sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -S
>/dev/null 2>&1 || :
There are several problems here.  One i810_audio does not exist. I
tried to modprobe it just for grins.  It must be the old OSS driver. 
However, when I peform an lsmod I see all the correct ALSA drivers
including the ALSA OSS emulation modules.  Two the post-install and
pre-remove commands still deal with aumix and not alsactl.  I wanted
to use mythtv.sf.net on a machine with the same motherboard.  I
performed a fresh install.  My modules.conf had no sound entries. 
However the modprob.conf had this
alias snd-card-0 snd-intel8x0
install snd-intel8x0 /sbin/modprobe --ignore-install snd-intel8x0 &&
/usr/sbin/alsactl restore >/dev/null 2>&1 || :
remove snd-intel8x0 { /usr/sbin/alsactl store >/dev/null 2>&1 || : ;
}; /sbin/modprobe -r --ignore-remove snd-intel8x0
So this cleanly installed machine restores my sound state at boot
time.  My snd-intel8x0 driver was correctly detected.

n the ALSA documentation for my on-board sound chip and other searches
I found several items that raise questions in my mind.  One is why FC2
does not use the gnome ALSA mixer application.  Here's a link to the
screen shot
http://www.paw.co.za/projects/gnome-alsamixer/images/main.png.  This
says the app should be in the gnome-media rpm.  This application
supports ALSA natively.  The gstreamer application does not let me
change the volume correctly with the ALSA tab.  I have to use the OSS
emulation tab.  Otherwise the volume cuts out on the ALSA tab.

The documentation for my card
said to use the util/alsasound file in the /etc/rc.d/init.d and set
the correct runlevels for it.  This is right before the “Setting up
modprobe and kmod support” section.  I don't understand why this file
is not used verses the modprobe.conf above?  I have attached it.  I
found the file in the alsa-driver-1.0.5a.tar.bz2 tar file.  There are
some nice error messages that may be useful.  One message is displayed
when a mixer has not been used to set the volume levels.   That could
be useful in the /var/log files for trouble shooting.  It also looks
like there is a design in the ALSA system to mute all controls upon
first install.  Hence, I don't think the recommendation to make the
sound level a kernel issue will be recognized as a kernel bug. 
However, the /usr/bin/system-config-soundcard utility seems pointless.
 The only reason I can think that the utility would play a sound and
not set the ALSA mixer levels to a sane setting is that it is designed
for the FC1 and prior versions amixer installation.  The application
does correctly detect my snd-intel8x0 driver at a sane audio level. 
Why not call alsactl and save the settings here in this application
during first boot?

Also I had to use the gnome-sound-properties to check both “Enable
sound server startup” and the “Sounds for Events” boxes on the
“General” tab.  This configures the gnome sound server to multiplex
multiple sound sources over the same PCM channel.  I don't believe my
on-board chip has a Emu10k chip that allows mutiple programs access to
the PCM channel at the same time like an SB Live or Audigy card does.
 I would think that the system-config-soundcard utility should do this
at first boot too or offer check boxes for the user to make the choice
at that time.  The debate here is whether gnome EsounD or the KDE
artsd sound servers. Perhaps the system-config-soundcard utility
should just pick one and not even offer a choice except to enable or
disable “Sound for Events”.

My final question is that I can fix my problem with the modprobe.conf
file from my clean FC2 install.  However, what would be the Red Hat
way of making this change or does that matter?

Some other links

The most helpful information on this topic came from
http://www.linuxformat.co.uk/.  However, I cannot find a link to their
“Better Sound” tutorial as found in the “The Complete Linux Handbook2”
found on magazine stands.

I wish I could find the original fedora-list posting that started me
down this path to give the guy credit too.
Comment 12 Greg Morgan 2004-07-11 15:31:12 EDT
Created attachment 101799 [details]
alsa /etc/rc.d/init.d script

Why not use this verses the modprobe.conf install settings?
Comment 13 Greg Morgan 2004-07-11 18:32:14 EDT
I made the changes to /etc/modprobe.conf that removed the amixer stuff
and added the alsactl settings from the cleanly installed FC2 machine.
My final file on the FC1 to FC2 upgraded machine looks like this.
# Note: for use under 2.4, changes must also be made to modules.conf!
alias eth0 e1000
alias usb-controller ohci-hcd
# alias snd-card-0 snd-intel8x0
# install sound-slot-0 /sbin/modprobe --first-time --ignore-install
sound-slot-0 && { /bin/aumix-minimal -f /etc/.aumixrc -L >/dev/null
2>&1 || :; }
# install sound-slot-0 /sbin/modprobe pcspkr && /sbin/modprobe
--first-time --ignore-install sound-slot-0 && { /bin/aumix-minimal -f
/etc/.aumixrc -L >/dev/null 2>&1 || :; }
# remove sound-slot-0 { /bin/aumix-minimal -f /etc/.aumixrc -S
>/dev/null 2>&1 || :; } ; /sbin/modprobe -r --first-time
--ignore-remove sound-slot-0
alias snd-card-0 snd-intel8x0
install snd-intel8x0 /sbin/modprobe --ignore-install snd-intel8x0 &&
/usr/sbin/alsactl restore >/dev/null 2>&1 || :
remove snd-intel8x0 { /usr/sbin/alsactl store >/dev/null 2>&1 || : ;
}; /sbin/modprobe -r --ignore-remove snd-intel8x0

I also commented out the old settings in the /etc/modules.conf file. 
This file looks like this.  I have a feeling that the other settings
are not required too.
alias eth0 e1000
alias usb-controller usb-ohci
# alias sound-slot-0 i810_audio
# post-install sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -L
>/dev/null 2>&1 || :
# pre-remove sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -S
>/dev/null 2>&1 || :
# Note: for use under 2.6, changes must also be made to modprobe.conf!

These two file changes renable sound on a reboot.  I also have a
feeling changes like this would work for rh 7.3, 8.0, 9.0, and rhe
upgrades to a 2.6 kernel running ALSA drivers natively verses the
depricated OSS drivers.
Comment 14 Greg Morgan 2004-07-11 18:56:15 EDT
Ahh...here are the original messages that put me on the right path. 
These messages and the two "Complete Linux Handbook2" articles helped
me to sort out and understand the problem.  Hopefully, all this
information will help spark a final solution.  The conversion to ALSA
sound problem appears to be one of the most perplexing problem on the

Amadeus W.M.
Chris Kloiber
Brian Hartman
Comment 15 Bill Nottingham 2004-07-12 16:47:33 EDT
Basically, the aumix... lines need rewritten on upgrade to alsactl
lines; it's a known deficiency ATM.
Comment 16 Greg Morgan 2004-07-17 13:55:57 EDT
Created attachment 102002 [details]
Changed app to save aumix and alsa mixer setting on press of ok

Full application file so that others can copy the file to
/usr/share/system-config-soundcard directory.  This and the soundcardBackend.py
file will fix this bug as far as making the app useful.
Comment 17 Greg Morgan 2004-07-17 14:00:09 EDT
Created attachment 102003 [details]
Added a saveVolume method cloned from setVolume use with 102002

This is the supporting file for 102002.  The soundcardBackend.py file was
changed to add a saveVolume method.  This method is called from the
system-config-soundcard application to save the alsa mixer settings once the
sound was played.
Comment 18 Greg Morgan 2004-07-17 14:33:00 EDT
As noted in Additional Comment #11
Why not call alsactl and save the settings here in this application
during first boot?

I just added two files to fix this bug.  I attached the entire files
by design.  The solution then is
1.) Save both attachment 102002 [details] and 102003 to your file system.  In
this example save them to /tmp.
2.) Start a terminal session by fedora menu>System Tools>Terminal
3.) su - root
4.) cd /usr/share/system-config-soundcard
5.) cp /tmp/soundcardBackend.py .
    cp /tmp/soundcard.py .
6.) Run application with fedora menu>System Settings>Soundcard Detection
   a.) Play the test sound.
   b.) Press ok.
   c.) Now your mixer settings are saved.  On a 2.4 kernel aumix is
used to save the mixer state to /etc/.aumixrc while on a 2.6 kernel
alsactl is used to save the mixer state to /etc/asound.state.
   d.) I performed a 2.6 test on my computer.  I was not able to test
on FC1, a 2.4 kernel. However, I ran the aumix command at the command
line to test that it would work.

Proof of solution involved removing the /etc/asound.state file; using
the app; and finally making sure that the file was there.  I had saved
my original asound.state file so that I could look at the difference
in sould levels.
[root@kids system-config-soundcard]# ls -l /etc/asound.state
-rw-r--r--  1 root root 4638 Jul 17 10:48 /etc/asound.state
[root@kids system-config-soundcard]# date
Sat Jul 17 10:48:45 MST 2004
[root@kids system-config-soundcard]# rm /etc/asound.state
rm: remove regular file `/etc/asound.state'? y
[root@kids system-config-soundcard]# !ls
ls -l /etc/asound.state
ls: /etc/asound.state: No such file or directory

Now I executed the changed application.

[root@kids system-config-soundcard]# !ls
ls -l /etc/asound.state
-rw-r--r--  1 root root 4638 Jul 17 10:49 /etc/asound.state
[root@kids system-config-soundcard]# diff /etc/asound.state
<               value.0 23
<               value.1 23
>               value.0 22
>               value.1 24

For upgrades that do not call firstboot a python import of the
proposed modification of
/usr/share/system-config-soundcard/soundcardBackend along with a call
to setVolume() and saveVolume() after the sound card has been detected
may solve this problem too.

Finally, I referenced this bug number in the changes and provided
limited documentation of the change.  Existing code in each file was
hacked and wacked to make the change.
Comment 19 Bill Nottingham 2004-09-20 17:23:43 EDT
*** Bug 133002 has been marked as a duplicate of this bug. ***
Comment 22 Brent Fox 2004-11-02 11:26:01 EST
Greg, as I said in my original post when I opened this bug report, I
don't think that it's the job of firstboot or any other config tool to
work around what is a bad default setting in the drivers.  Many people
who do kickstart or text-only installs will not run firstboot and
therefore will not get the volume setting set to something non-zero.

I guess that they could do something in %post to turn up the volume,
but again, that would make users take extra steps just to fix
something that should have been right by default.
Comment 23 Dave Jones 2005-04-16 00:38:37 EDT
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat.  The Fedora legacy project will be producing further kernel
updates for security problems only.

If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.

Thank you.

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