Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 527769 - Volume control slider only mutes
Summary: Volume control slider only mutes
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 12
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jaroslav Kysela
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2009-10-07 16:12 UTC by Tim Waugh
Modified: 2010-12-04 07:32 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-12-04 07:32:36 UTC
Type: ---

Attachments (Terms of Use)
Result of alsa-info.sh --no-upload (14.26 KB, text/plain)
2009-10-07 16:12 UTC, Tim Waugh
no flags Details
Produced by 'alsa-info.sh --no-upload' (16.64 KB, text/plain)
2010-01-31 19:13 UTC, Dan Krejsa
no flags Details
dmesg output showing two attempts to rmmod snd-hda-intel and then reload it with the single_cmd=1 option (43.36 KB, text/plain)
2010-02-06 03:20 UTC, Dan Krejsa
no flags Details

Description Tim Waugh 2009-10-07 16:12:59 UTC
Created attachment 363996 [details]
Result of alsa-info.sh --no-upload

Description of problem:
The GNOME volume control slider has no effect on the sound volume until it is very near the bottom, at which point it mutes the sound.

Version-Release number of selected component (if applicable):

How reproducible:

I am using the built-in speaker.

Comment 1 Bastien Nocera 2009-10-07 16:33:21 UTC
Try with gnome-media-2.28.1

Comment 2 Tim Waugh 2009-10-07 16:53:38 UTC


Comment 3 Bastien Nocera 2009-10-07 17:33:56 UTC
The problem is that the volume doesn't change at all, right?

Does using pavucontrol change the volume as expected?

Comment 4 Tim Waugh 2009-10-08 09:09:12 UTC
Adjusting the output volume in pavucontrol shows the same problem.  Thanks for the pointer.

Changing component to pulseaudio.

Comment 5 Lennart Poettering 2009-10-14 21:43:01 UTC
Does changing the output port or profile change anything? (i.e. both are accessible in pavucontrol and g-v-c). Most likely this is caused by a mislabeling of the device controls by the driver: i.e. the "Speaker" control does not actually control the Speaker. Could you verify that by playing with the low level mixer? "alsamixer -c0" should give you access to all controls.

Comment 6 Tim Waugh 2009-10-16 14:00:44 UTC
There isn't another output port to try unfortunately, just 'Internal Audio Analog Stereo (Stereo)'.

Changing profile from duplex to output doesn't change anything.

Using 'alsamixer -c0' I can see three playback controls: 'Master', 'PCM' and 'LFE'.  Changing 'PCM' or 'LFE' controls individually correctly changes the volume; changing 'Master' has no effect except for muting the sound when at 0.

Comment 7 Lennart Poettering 2009-10-16 14:03:33 UTC
Ok, if 'Master' has no effect on the volume then this is certainly a driver problem/mislabelling.

Reassigning to the kernel/modules.

Please include the output of 'alsa-info.sh --no-upload' so that your card can be properly identified.

Comment 8 Tim Waugh 2009-10-16 14:14:53 UTC
(In reply to comment #7)
> Ok, if 'Master' has no effect on the volume then this is certainly a driver
> problem/mislabelling.

Thanks for diagnosing.

> Please include the output of 'alsa-info.sh --no-upload' so that your card can
> be properly identified.  

See comment #0.

Comment 9 Bug Zapper 2009-11-16 13:22:51 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:

Comment 10 Dan Krejsa 2010-01-31 19:13:41 UTC
Created attachment 387874 [details]
Produced by 'alsa-info.sh --no-upload'

Comment 11 Dan Krejsa 2010-01-31 19:24:37 UTC
I also see this issue after installing Fedora 12.  The Master volume control completely cuts off the sound at low settings, and at higher settings the sound volume is high and unrelated to the so-called 'Master volume control'; however, the 'Master volume control' setting does seem to have some effect on the left-right balance.

I'm using Intel HDA, SigmaTel STAC9200 codec on a Dell XPS M1710.

Is there an upstream bug (or even a suggestion about an upstream component bug tracker where I could track or report this issue)?

Comment 12 Jaroslav Kysela 2010-02-01 12:38:06 UTC
According the source code, HDA codec node 0x0b should control the master volume for this codec. Could you use the hda-analyzer tool (run as root):

wget -O run.py http://www.alsa-project.org/hda-analyzer.py
python run.py --monitor

And check what node changes when you modify Master volume control in 'alsamixer -c0'.

Comment 13 Tim Waugh 2010-02-01 13:03:48 UTC
For me, yes, it's 0x0b that changes.  For example:

Node 0x0b [Audio Selector] wcaps 0x300105: Stereo Amp-Out
   Amp-Out caps: N/A
-  Amp-Out vals: [0x1e 0x1e]
+  Amp-Out vals: [0x12 0x12]
   Connection: 1

Comment 14 Jaroslav Kysela 2010-02-01 13:26:37 UTC
Nice. And what's the range for values (zero volume ... max volume in alsamixer)? From dump it should be in range 0x00 .. 0x1f:

Default Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=1

Also, you may play in the hda-analyzer GUI (just run "python run.py" command without arguments) with the node 0x0b (and maybe with other nodes) to determine the hardware behaviour.

Comment 15 Tim Waugh 2010-02-01 14:00:58 UTC
Yes, 0x00 .. 0x1f.  "python run.py" allows me to control left and right channels correctly.

Comment 16 Jaroslav Kysela 2010-02-01 17:20:31 UTC
If I understand your sentence correctly:

- using alsamixer the values from node 0x0b changes from 0x00 .. 0x1f, but the master volume does not behave correctly (wrong volume levels)

- if you change volume values from node 0x0b in hda-analyzer, then output volume
changes as expected?

Both ways should do same. The values are read directly from hardware.

Comment 17 Dan Krejsa 2010-02-02 05:12:53 UTC
Hi, I'm getting the following python exception when I try to run the tool:
[dlkrejsa@localhost ~]$ sudo python run.py --monitor
Using temporary directory: /dev/shm/hda-analyzer
You may remove this directory when finished or if you like to
download the most recent copy of hda-analyzer tool.
Downloading file hda_analyzer.py
Downloading file hda_codec.py
Downloading file hda_proc.py
Downloaded all files, executing hda_analyzer.py
Traceback (most recent call last):
  File "/dev/shm/hda-analyzer/hda_analyzer.py", line 1030, in <module>
  File "/dev/shm/hda-analyzer/hda_analyzer.py", line 1012, in main
    if read_nodes(sys.argv[1:]) == 0:
  File "/dev/shm/hda-analyzer/hda_analyzer.py", line 92, in read_nodes
    read_nodes2(c.card, i)
  File "/dev/shm/hda-analyzer/hda_analyzer.py", line 72, in read_nodes2
  File "/dev/shm/hda-analyzer/hda_codec.py", line 841, in analyze
    pcm = self.param_read(self.afg, PARAMS['PCM'])
  File "/dev/shm/hda-analyzer/hda_codec.py", line 765, in param_read
    return self.rw(nid, VERBS['PARAMETERS'], param)
  File "/dev/shm/hda-analyzer/hda_codec.py", line 750, in rw
    verb = (nid << 24) | (verb << 8) | param
TypeError: unsupported operand type(s) for <<: 'NoneType' and 'int'
[dlkrejsa@localhost ~]$
The 'nid' argument in the call to self.rw() is None, which means that
self.afg is None at the call to self.param_read on line 841 in the
analyze() function of class HDACodec. I added the instrumentation
to the loop that is supposed to set self.afg :

    total, nid = self.get_sub_nodes(AC_NODE_ROOT)
    print 'total, nid =', total, nid
    for i in range(total):
      self.function_id = func = self.param_read(nid, PARAMS['FUNCTION_TYPE'])
      print 'nid=%d, func = %x' % (nid,func)
      if (func & 0xff) == 0x01:		# audio group
        self.afg = nid
      elif (func & 0xff) == 0x02:	# modem group
        self.mfg = nid
      nid += 1

and the output printed is 
Downloaded all files, executing hda_analyzer.py
total, nid = 1 1
nid=1, func = 101
total, nid = 1 2
nid=2, func = 102
nid, verb =  None 3840
Traceback (most recent call last):
  File "/dev/shm/hda-analyzer/hda_analyzer.py", line 1030, in <module>
  File "/dev/shm/hda-analyzer/hda_analyzer.py", line 1012, in main
    if read_nodes(sys.argv[1:]) == 0:
  File "/dev/shm/hda-analyzer/hda_analyzer.py", line 92, in read_nodes
    read_nodes2(c.card, i)
  File "/dev/shm/hda-analyzer/hda_analyzer.py", line 72, in read_nodes2
  File "/dev/shm/hda-analyzer/hda_codec.py", line 845, in analyze
    pcm = self.param_read(self.afg, PARAMS['PCM'])
  File "/dev/shm/hda-analyzer/hda_codec.py", line 767, in param_read
    return self.rw(nid, VERBS['PARAMETERS'], param)
  File "/dev/shm/hda-analyzer/hda_codec.py", line 752, in rw
    verb = (nid << 24) | (verb << 8) | param
TypeError: unsupported operand type(s) for <<: 'NoneType' and 'int'

so it looks like since nid starts out at 2 in the loop on the call to
analyze that fails, and the function type parameter returns 2 for that nid,
and total==1 so there is only one iteration of the loop, the 'audio group'
case line that sets self.afg never gets executed.  But that's as far as I can go without actually understanding what I'm talking about.

Comment 18 Dan Krejsa 2010-02-02 06:05:49 UTC
Guessing that the script was having problems with this codec (from
the alsa-info.sh output):

Codec: Conexant ID 2bfa
Address: 1
Function Id: 0x2
Vendor Id: 0x14f12bfa
Subsystem Id: 0x14f100c3
Revision Id: 0x90000
Modem Function Group: 0x2

I artificially terminated the loop in the script so that the problem
case of the Conexant codec wasn't hit.  Then when I modify the 'Master'
control in the 'alsamixer -c0' application I get changes in Node 0x0b

Diff for codec 0/0 (0x83847690):
@@ -74,17 +74,17 @@
      0x05* 0x0a
 Node 0x0a [Audio Selector] wcaps 0x30090d: Stereo Amp-Out R/L
   Amp-Out caps: ofs=0x00, nsteps=0x0f, stepsize=0x05, mute=1
   Amp-Out vals: [0x0a 0x0a]
   Connection: 1
 Node 0x0b [Audio Selector] wcaps 0x300105: Stereo Amp-Out
   Amp-Out caps: N/A
-  Amp-Out vals: [0x12 0x12]
+  Amp-Out vals: [0x14 0x14]
   Connection: 1
 Node 0x0c [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
   Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
   Amp-Out vals: [0x00 0x00]
   Connection: 5
      0x10* 0x0f 0x0e 0x0d 0x12
 Node 0x0d [Pin Complex] wcaps 0x400181: Stereo

The Amp-Out values reported do seem to range between 0 and 0x1f
as the slider goes from all the way off to all the way on.

Changes in the PCM control, which does effectively control the volume, do not
seem to appear in the diff output; I'm not sure whether that's expected or not.
Also, there seem to be some periodic changes involving 'Pin-ctls' lines in
many nodes that disappear or reappear even when I'm not touching the alsamixer controls.

Modifying the Master control doesn't affect the volume unless the control's
value is 0x00, as shown by alsimixer (although not by gnome) in which case the output is muted.  Otherwise, it seems to affect the balance, or perhaps the bass. (To me, low values of the control seem lower in pitch, and higher values seem higher in pitch and more to the right side -- but maybe my ears are funny.)

Comment 19 Jaroslav Kysela 2010-02-02 07:53:52 UTC
I fixed the issue with the modem codec in hda-analyzer now.

Unfortunately, I don't know how to fix this issue. The datasheet for STAC9200 is at http://www.idt.com/?genId=STAC9200 - Documents. The node 0x0b should control the master volume. Also, there should be node 0x14 which controls the Beep (mono output) volume. Perhaps, you may also try this node if it does something for your system.

Comment 20 Tim Waugh 2010-02-02 11:00:21 UTC
Hmm, testing it again it seems that the volume slider is working as expected for me now. :-/

Comment 21 Dan Krejsa 2010-02-05 03:53:09 UTC
Unfortunately, not for me, the master volume control is still not controlling
the volume.
Perhaps the fact that it worked in Fedora 11 might point at an avenue for

By the way, the new diagnostic hda-analyzer is failing for me in a new way:

[dlkrejsa@localhost ~]$ sudo python run.py --monitor
Using temporary directory: /dev/shm/hda-analyzer
You may remove this directory when finished or if you like to
download the most recent copy of hda-analyzer tool.
File cached /dev/shm/hda-analyzer/hda_analyzer.py
File cached /dev/shm/hda-analyzer/hda_codec.py
File cached /dev/shm/hda-analyzer/hda_proc.py
Downloaded all files, executing hda_analyzer.py
Watching 1 cards
Traceback (most recent call last):
  File "/dev/shm/hda-analyzer/hda_analyzer.py", line 1072, in <module>
  File "/dev/shm/hda-analyzer/hda_analyzer.py", line 1065, in main
  File "/dev/shm/hda-analyzer/hda_analyzer.py", line 1032, in monitor
  File "/dev/shm/hda-analyzer/hda_codec.py", line 892, in reread
AttributeError: HDACodec instance has no attribute 'gpio'
Exception AttributeError: "HDACodecProc instance has no attribute 'fd'" in <bound method HDACodecProc.__del__ of <hda_proc.HDACodecProc instance at 0x9ea05ec>> ignored

Comment 22 Dan Krejsa 2010-02-05 04:17:07 UTC
Hmm, I just found something.  When I run the hda-analyzer without the --monitor
argument to run.py, if I click on the Revert button, the volume control goes
back to behaving correctly (at least the volume varies, although the balance might be a bit off and the highest volume seems a bit low).  However, as soon as I adjust the volume so low that it mutes, or directly mute the volume, the volume control goes back to the old bad behavior -- all very loud when not muted.  This is repeatable for me.

Comment 23 Jaroslav Kysela 2010-02-05 09:23:07 UTC
I've fixed the issuse in comment#21 in git tree.

Could you load the snd-hda-intel module with 'single_cmd=1' module parameter?

# fuser /dev/snd/*
# kill -9 <all_shown_pids>
# rmmod snd-hda-intel
# modprobe snd-hda-intel single_cmd=1

... check the mixer now ...

It looks like that the communication between HDA codec and HDA PCI bridge is broken. Or it might be just a hw bug in the codec.

Comment 24 Dan Krejsa 2010-02-05 16:30:46 UTC
Hi, I don't have time to try that right now, I'll try later this evening.
However, I need to clarify my previous comment.  After reverting the settings
of codec-0 using the hda-analyzer gui,
when I decrease the volume to 0 or mute the volume using the 'alsamixer -c0' tool,
the volume does NOT get into the bad state -- when I raise or unmute the master volume control again, it still works, controlling the volume.  It's only when I decrease the volume to zero or mute using the gnome volume control (or the physical volume buttons on the front of the laptop, which I guess goes through the same code) that the volume gets very loud and stops being limited by the master volume control.

Comment 25 Dan Krejsa 2010-02-06 03:19:33 UTC
While in a graphical session, as fast as I killed off the PIDs listed by 'fuser /dev/snd/*', new ones came back to life.  So I did 'telinit 3', and was then
able to kill the processes and rmmod snd-hda-intel, then reload it with the single_cmd=1 option.  However, after doing that, no sound cards at all show up.

[dlkrejsa@localhost asound]$ cat /proc/asound/cards
--- no soundcards ---

There were some kernel messages from when I reloaded the snd-hda-intel module,
I'll attach a dmesg log showing two attempts to remove and reload the module.

Comment 26 Dan Krejsa 2010-02-06 03:20:47 UTC
Created attachment 389236 [details]
dmesg output showing two attempts to rmmod snd-hda-intel and then reload it with the single_cmd=1 option

Comment 27 Dan Krejsa 2010-02-06 03:25:11 UTC
What's different about the way the hardware is touched when I mute and then unmute the volume using the gnome volume control, vs. the way it is touched when I mute and unmute it using 'alsamixer -c0' ?

Comment 28 Dan Krejsa 2010-02-07 18:19:43 UTC
Something new.  Any adjustments to the volume up or down using the gnome volume control move the LFE setting to 100%, which results in very loud (low frequency) sound that makes it hard to hear the volume changes made by the master volume
control widget, and mislead me to believe that the master volume control was adjusting bass or balance or something rather than overall volume.

So, better definition of the problem:
Adjusting the overall volume setting up or down (although not, as I had thought earlier, just the mute checkbox) in gnome volume control results in immediately setting the LFE setting to 100%, regardless of the Master volume control widget setting.

Comment 29 Dan Krejsa 2010-02-07 18:35:33 UTC
I don't know if this would be expected or not, but the 'run.py --monitor' script shows no differences when the LFE control is adjusted via alsamixer.

Comment 30 Dan Krejsa 2010-02-08 16:32:04 UTC
I think the behavior that I noticed in comments #22 and #25 must mean that when
I click the 'revert' button in the hda-analyzer gui, it is muting the LFE, so
so that the it doesn't matter that adjusting the Output Volume via gnome-volume-control immediately adjusts the LFE level to 100%. Only when g-v-c does an unmute operation does LFE (as well as the Master widget) get unmuted.

I don't see feedback in the alsamixer gui that shows the LFE getting muted when
I click the Revert button for codec 0 in the hda-analyzer gui, though.

Comment 31 Dan Krejsa 2010-02-08 17:03:12 UTC
I tried using 'options snd_hda_intel model=ref' in a newly created
/etc/modprobe.d/snd_hda_intel.conf file.  That simply eliminated the LFE.
Perhaps there's a different model that would match better -- how could I
determine which one to use other than simply trying them all?  Assuming one
works, how could one ensure that the right configuration would be chosen automatically in the future?

Comment 32 Jaroslav Kysela 2010-02-08 17:17:18 UTC
The defaults are hardcoded in the snd-hda-intel driver. Please, confirm that this model works without any issues for you and I can add a default entry for your hw to the driver.

Comment 33 Dan Krejsa 2010-02-09 05:53:46 UTC
None of the models listed in HD-Audio-Models.txt really work the way
I expect. Below are the results.  I list what controls are visible in
alsamixer with the configuration. My laptop is in fact a Dell XPS M1710,
and using the dell-m23 model I get the same results as with the default (no
'model' option specified to snd_hda_intel) -- i.e., as described above.

Actually, any of the settings without LFE (except dell-d23) would be an improvement in that there wouldn't be the loud, constant 100% LFE signal that I presently have.  But I want the LFE output, I just want its level controlled reasonably together with the Master volume when I change the 'output volume' in gnome-volume-control or equivalent.  As I'm not much of an audiophile, I care not as much about whether there is an LFE control visible in alsamixer, although I would prefer that there were, if only to verify whether or not any LFE output is present by muting it and listening for the difference. (It's not always easy to tell -- certainly any LFE output that might be present when the LFE control is not present in alsamixer is not as loud as the 100% output I get by default now -- which is a good thing.  But 'full, rich sound' is nice too.)

So, is it possible to keep the LFE control in alsamixer but also have
the default LFE level adjusted together with the Master Volume when I
adjust the 'output volume' in gnome-volume-control?


oqo           OQO Model 2
dell-m24      Dell Latitude 120L
dell-m26      Dell Inspiron 1501
gateway-m4    Gateway laptops with EAPD control
gateway-m4-2  Gateway laptops with EAPD control
auto          BIOS setup (default)
        No LFE (Master, PCM)

dell-m23        Dell XPS M1710, Dell Precision M90
dell-m27        Dell Inspiron E1705/9400
        (Master, PCM, LFE, S/PDIF, S/PDIF Default)
        Same behavior as no default; LFE goes to 100% when g-v-c
        output volume adjusted ==> loud, low-pitch 100% LFE output
        plus output controlled by master volume control

ref           Reference Board
dell-d21      Dell (unknown)
dell-d22      Dell (unknown)
dell-m21      Dell Inspiron 630m, Dell Inspiron 640m
dell-m22      Dell Latitude D620, Dell Latitude D820
dell-m25      Dell Inspiron E1505n
panasonic     Panasonic CF-74
        No LFE.  (Master, PCM, S/PDIF, S/PDIF Default PCM)

dell-d23      Dell (unknown)
        (Master, PCM, LFE) No sound at all.

Comment 34 Dan Krejsa 2010-02-09 17:04:03 UTC
Strictly, I want adjusting the output volume using gnome-volume-control or equivalent to scale the actual LFE output from the subwoofer.

g-v-c, or pulse-audio, or whoever is responsible, seems to assume that the LFE control is in fact scaled subordinate to the Master volume widget, otherwise it would make absolutely no sense to set LFE to 100% whenever the output volume is adjusted. (Even if LFE were subordinate to the Master volume widget, setting LFE
to 100% always doesn't make a lot of sense since it means losing any tweaks to
LFE by alsamixer or some other mixer program every time the output volume is adjusted.)  Since the hardware evidently isn't set up with LFE subordinate to and scaled by the Master volume widget, then I guess there are several possibilities:

-- g-v-c, or pulseaudio, or some such upper-level software should realize that
   and scale LFE in conjunction with the Master volume widget as 'output volume'
   is adjusted

-- snd_hda_intel or alsa or some lower-level software should make the device
   appear to higher level software as if LFE was scaled by and subordinate to
   the Master volume widget

-- throw up hands and say, this hardware is too weird, we're not going to
   support devices with LFE not subordinate to the Master volume widget.

Probably you can think of many other possibilities; but since I'm a newbie, I don't even have a good idea of what _should_ be the behavior, and I'm not even sure my analysis is even on mark.

Comment 35 Dan Krejsa 2010-02-14 04:02:47 UTC
A couple of questions:

- Do you need any more information from me on this issue?

- Do you think that there is a chance in the near term of a fix better than using one of the HDA models in which the LFE control is not visible?

If no to both, and if you think it's appropriate, it's OK with me if this issue is closed.

 - Dan

Comment 36 Bug Zapper 2010-11-04 09:35:53 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 37 Bug Zapper 2010-12-04 07:32:36 UTC
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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