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): gnome-media-2.28.0-2.fc12.x86_64 pulseaudio-0.9.19-1.fc12.x86_64 How reproducible: 100% I am using the built-in speaker.
Try with gnome-media-2.28.1
Same. gnome-media-2.28.1-1.fc12.x86_64
The problem is that the volume doesn't change at all, right? Does using pavucontrol change the volume as expected?
Adjusting the output volume in pavucontrol shows the same problem. Thanks for the pointer. Changing component to pulseaudio.
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.
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.
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.
(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.
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Created attachment 387874 [details] Produced by 'alsa-info.sh --no-upload'
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)?
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'.
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 0x07
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.
Yes, 0x00 .. 0x1f. "python run.py" allows me to control left and right channels correctly.
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.
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> sys.exit(main(sys.argv)) 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 c.analyze() 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 else: break 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> sys.exit(main(sys.argv)) 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 c.analyze() 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.
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 --endcollapse-- 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 0x0c 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 0x07 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.)
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.
Hmm, testing it again it seems that the volume slider is working as expected for me now. :-/
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 investigation? 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> sys.exit(main(sys.argv)) File "/dev/shm/hda-analyzer/hda_analyzer.py", line 1065, in main monitor() File "/dev/shm/hda-analyzer/hda_analyzer.py", line 1032, in monitor c.reread() File "/dev/shm/hda-analyzer/hda_codec.py", line 892, in reread self.gpio.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
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.
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.
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.
Hi, 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.
Created attachment 389236 [details] dmesg output showing two attempts to rmmod snd-hda-intel and then reload it with the single_cmd=1 option
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' ?
Hi, 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.
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.
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.
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?
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.
Hi, 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 <default> (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.
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.
Hi, 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. Thanks, - Dan
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.