Created attachment 438401 [details] The alsa-info.sh output for the laptop with F13 i686 Description of problem: The speakers don't mute when headphones plugged in. This happens on both of my systems, an x86_64 dual core I put together, which uses an Asus motherboard, and an Asus eee1000HD. While the former machine is new, so I can't comment on earlier versions of Fedora, AFAIK, the latter machine, which has had F9, F10, F11 and F12 previously loaded, did not previously suffer from this problem; it started with F13. This is a new install on both machines. Version-Release number of selected component (if applicable): For the laptop (i686): [user@localhost ~]$ rpm -qa pulse* kernel alsa* |sort alsa-firmware-1.0.23-1.fc13.noarch alsa-lib-1.0.23-1.fc13.i686 alsa-plugins-pulseaudio-1.0.22-1.fc13.i686 alsa-tools-firmware-1.0.23-1.fc13.i686 alsa-utils-1.0.23-3.fc13.i686 kernel-2.6.33.5-124.fc13.i686 kernel-2.6.33.6-147.fc13.i686 kernel-2.6.33.6-147.2.4.fc13.i686 pulseaudio-0.9.21-6.fc13.i686 pulseaudio-libs-0.9.21-6.fc13.i686 pulseaudio-libs-glib2-0.9.21-6.fc13.i686 pulseaudio-module-x11-0.9.21-6.fc13.i686 pulseaudio-utils-0.9.21-6.fc13.i686 [root@localhost ~]# dmidecode <SNIP> Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: ASUSTeK Computer INC. Product Name: 1000H Version: x.x Serial Number: 89OAAQ454336 UUID: 80C2A841-DC8A-DD81-2202-002354291C45 Wake-up Type: Power Switch SKU Number: 90OAM0TB8C211131U11HQ Family: To Be Filled By O.E.M. Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: 1000H Version: x.xx Serial Number: EeePC-0123456789 Asset Tag: To Be Filled By O.E.M. Features: Board is a hosting board Board is replaceable Location In Chassis: To Be Filled By O.E.M. Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 <SNIP> [root@localhost ~]# I am now away from home, so I can't report on the desktop yet. But from another bug report, I can at least report this: Some more data: [root@localhost ~]# rpm -q kernel kernel-2.6.33.5-124.fc13.x86_64 kernel-2.6.33.6-147.fc13.x86_64 kernel-2.6.33.6-147.2.4.fc13.x86_64 [root@localhost ~]# dmidecode <SNIP> Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: M4A88T-M <SNIP> Handle 0x0004, DMI type 4, 40 bytes Processor Information Socket Designation: AM3 <SNIP> [root@localhost ~]# How reproducible: Every time (on rare occasions, I believe the desktop was properly switching, but it is so rare it could be a fatah morgana ;-)). Steps to Reproduce: 1. plug in headphones 2. play sound 3. put headphone in one ear 4. hear sound coming from both headphones and speakers Actual results: Hear sound coming from both headphones and speakers Expected results: Hear phones only from headphones, except when not plugged in, at which point sound should come from speakers. Additional info: This bug seems identical with, WITH TWO CAVEATS (see after list): https://bugzilla.redhat.com/show_bug.cgi?id=529580 https://bugzilla.redhat.com/show_bug.cgi?id=540366 https://bugzilla.redhat.com/show_bug.cgi?id=540402 https://bugzilla.redhat.com/show_bug.cgi?id=582798 https://bugzilla.redhat.com/show_bug.cgi?id=587972 https://bugzilla.redhat.com/show_bug.cgi?id=588722 https://bugzilla.redhat.com/show_bug.cgi?id=591523 https://bugzilla.redhat.com/show_bug.cgi?id=596930 https://bugzilla.redhat.com/show_bug.cgi?id=600944 https://bugzilla.redhat.com/show_bug.cgi?id=612769 The caveat is that (a) I played around with different modprobe settings on my desktop, to no avail. I would be really neat to have an easier way to figure out what the proper settings are, for now, it is hit or miss (mostly miss), and (b) since this is closely related to hardware, I assume you want as many different reports as possible in order to solve this bug as well as possible. I am attaching an attachment with alsa-info for the laptop (eee pc 1000hd)
I had the same problem. My card is this: # cat /proc/asound/card0/codec#0 Codec: Realtek ALC269 I have Lenovo SL510. Adding following to /etc/modprobe.conf/dist-alsa.conf solved the problem: options snd_hda_intel model=quanta You'd probably need to find the model of your card from the above command and then look it up here: http://lxr.linux.no/#linux+v2.6.35.5/Documentation/sound/alsa/HD-Audio-Models.txt And finally add the proper model= option in dist-alsa.conf This'll work till we have a proper fix.
Excellent. So now half of my problem is solved: On my laptop, which has the same chipset you have, Realtek ALC269, the system now properly probes when the headphones are plugged in, thanks to the following line I added to /etc/modprobe.conf/dist-alsa.conf options snd_hda_intel model=quanta Thank you. However, I still need some more help. On my desktop, I have the VIA VT1708S chipset, which is not featured (or at least I didn't see it) in http://lxr.linux.no/#linux+v2.6.35.5/Documentation/sound/alsa/HD-Audio-Models.txt What do I do for my VIA chipset?
CORRECTION: With the above setting (model=quanta), while the laptop's headphones worked properly, with the speakers muting, nonetheless, I discovered the microphone was out of order. I now use the following setting, and everything is fine and dandy, working as should be: options snd-hda-intel model=eeepc-3901 Reminder: this is an Asus eee 1000HD. It would be great if this type of thing could be automatically detected, or at least made easier to fix through a GUI. I actually like CLI configurations, but there are newbies bound to come up against this barrier, and Fedora should deal with this out of the box, no? And my desktop still suffers from this issue (see previous comment), so I would really appreciate some guidance on that (VIA VT1708S chipset).
I updated to Fedora 14, and the problem persists on the desktop (the VIA VT1708S chipset). I am updating the version against which this bug is reported.
Created attachment 458446 [details] Output of alsa-info.sh, for the x86_64 desktop The bug, as previously reported, persists, despite updating to Fedora 14. As the bug title indicates, when I plug in the headphones, I can hear sound from the headphones, but the regular speakers do not mute, which kind of defeats the reason for having headphones altogether. Since I updated to Fedora 14, here is the up to date information about the system, *in* *addition* to the attached output of alsa-info.sh: [root@localhost root]# rpm -qa pulse* kernel alsa* |sort alsa-firmware-1.0.23-1.fc14.noarch alsa-lib-1.0.23-1.fc14.i686 alsa-lib-1.0.23-1.fc14.x86_64 alsa-plugins-pulseaudio-1.0.22-1.fc13.i686 alsa-plugins-pulseaudio-1.0.22-1.fc13.x86_64 alsa-tools-firmware-1.0.23-1.fc14.x86_64 alsa-utils-1.0.23-3.fc14.x86_64 kernel-2.6.35.6-45.fc14.x86_64 kernel-2.6.35.6-48.fc14.x86_64 pulseaudio-0.9.21-6.fc13.x86_64 pulseaudio-libs-0.9.21-6.fc13.i686 pulseaudio-libs-0.9.21-6.fc13.x86_64 pulseaudio-libs-glib2-0.9.21-6.fc13.i686 pulseaudio-libs-glib2-0.9.21-6.fc13.x86_64 pulseaudio-module-x11-0.9.21-6.fc13.x86_64 pulseaudio-utils-0.9.21-6.fc13.x86_64 [root@localhost root]# cat /proc/asound/card1/codec#0 |grep Codec Codec: VIA VT1708S [root@localhost root]# dmidecode # dmidecode 2.10 SMBIOS 2.5 present. <SNIP> Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: M4A88T-M Version: Rev X.0x Serial Number: 105289970002059 Asset Tag: To Be Filled By O.E.M. Features: Board is a hosting board Board is replaceable Location In Chassis: To Be Filled By O.E.M. Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 Handle 0x0003, DMI type 3, 21 bytes Chassis Information Manufacturer: Chassis Manufacture Type: Desktop Lock: Not Present Version: Chassis Version Serial Number: Chassis Serial Number Asset Tag: Asset-1234567890 Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x00000001 Height: Unspecified Number Of Power Cords: 1 Contained Elements: 0 <SNIP> Handle 0x000D, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: Audio_Line_In Internal Connector Type: None External Reference Designator: Audio_Line_In External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x000E, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: Audio_Line_Out Internal Connector Type: None External Reference Designator: Audio_Line_Out External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x000F, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: Audio_Mic_In Internal Connector Type: None External Reference Designator: Audio_Mic_In External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x0010, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: Audio_Center/Sub Internal Connector Type: None External Reference Designator: Audio_Center/Sub External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x0011, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: Audio_Rear Internal Connector Type: None External Reference Designator: Audio_Rear External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x0012, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: Audio_Side Internal Connector Type: None External Reference Designator: Audio_Side External Connector Type: Mini Jack (headphones) Port Type: Audio Port Handle 0x0013, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: HDMI Internal Connector Type: None External Reference Designator: HDMI port External Connector Type: Other Port Type: Other <SNIP> Handle 0x0016, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SPDIFO Internal Connector Type: None External Reference Designator: SPDIF_OUT External Connector Type: Mini Jack (headphones) Port Type: Audio Port <SNIP> Handle 0x0024, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: SPDIF OUT Internal Connector Type: Other External Reference Designator: Not Specified External Connector Type: None Port Type: Other <SNIP> Handle 0x002E, DMI type 10, 6 bytes On Board Device Information Type: Sound Status: Enabled Description: To Be Filled By O.E.M. <SNIP> Handle 0x003E, DMI type 127, 4 bytes End Of Table [root@localhost root]#
I upgraded to FC15, and the problem persists on the x86_64 desktop above. What now?
My FC15 is up to date, and this bug is not fixed yet. Headphones are useless! Codec: VIA VT1708S alsa-firmware-1.0.24.1-2.fc15.noarch alsa-lib-1.0.24-2.fc15.i686 alsa-plugins-jack-1.0.24-2.fc15.i686 alsa-plugins-pulseaudio-1.0.24-2.fc15.i686 alsa-tools-firmware-1.0.24.1-2.fc15.i686 alsa-utils-1.0.24.1-3.fc15.i686 kernel-2.6.38.6-26.rc1.fc15.i686 kernel-2.6.40.6-0.fc15.i686 pulseaudio-0.9.22-5.fc15.i686 pulseaudio-gdm-hooks-0.9.22-5.fc15.i686 pulseaudio-libs-0.9.22-5.fc15.i686 pulseaudio-libs-glib2-0.9.22-5.fc15.i686 pulseaudio-module-bluetooth-0.9.22-5.fc15.i686 pulseaudio-module-gconf-0.9.22-5.fc15.i686 pulseaudio-module-x11-0.9.22-5.fc15.i686 pulseaudio-utils-0.9.22-5.fc15.i686 Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: K50AB Version: 1.00 BIOS Revision: 8.14
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached 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, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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