| Summary: | Headphone switch causes muted headphone/speaker output with pulesaudio enabled | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Tyler <ty.PixelPlane> |
| Component: | RPM Packages | Assignee: | Colin Guthrie <mageia> |
| Status: | RESOLVED OLD | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | mageia, sysadmin-bugs |
| Version: | 2 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | pulseaudio | CVE: | |
| Status comment: | |||
|
Description
Tyler
2012-05-11 22:27:47 CEST
Additional Information: The unit in question is a Asus G73SW Laptop with a realtek soundcard using the Intel HDA Driver.
Tyler
2012-05-11 22:35:00 CEST
Summary:
Headphone switch with pulseaudio causes muted headphone output =>
Headphone switch causes muted headphone/speaker output with pulesaudio enabled Bug still valid with the update ? Component:
Release (media or process) =>
RPM Packages (In reply to comment #2) > Bug still valid with the update ? Sadly yes. I also did a fresh install to change my partition format from xfs to ext4, so I can confirm it still exists on a freshly installed system. HOWEVER, the new pulseaudio update did make it so that sound does NOT remain muted when the headphones are unplugged (sound begins playing on the main speakers again, contrary to the initial bug report). However, the headphone audio itself is still muted when they're plugged in.
Manuel Hiebel
2012-05-14 18:57:00 CEST
Assignee:
bugsquad =>
mageia And I may have just discovered a fix. It's a little bit of a dirty fix, however, as it can't be applied to all hardware. The reason why this issue is occurring is for the reason I thought. Pulseaudio was muting the wrong alsa channel when the headphone switch was being tripped. My hardware is an oddity in that it uses "Speaker" in alsa for both headphone and speaker volume, and seems to use a hardware implemented switch to disable the built-in speakers. The fix is to edit the file /usr/share/pulseaudio/alsa-mixer/paths/analog-output-headphones.conf and edit the line [Element Speaker] switch = off volume = off to [Element Speaker] switch = mute volume = zero (Pulseaudio seems to control its headphone muting by using channel names, hence why my hardware is negatively affected) HOWEVER, I'm unsure if this fix would affect other hardware negatively. This code in the preference file actually hinted me into this fix: ; On some machines Front is actually a part of the Headphone path [Element Front] switch = mute volume = zero Seems they'd run into the problem before, and this was a quick fix for someone who's system used "Front" in the same way mine uses "Speaker". Note: My exact comments in the previous post are mostly speculation on how my hardware works. However, the fix is indeed working on my system. I can now use pulseaudio to manage my system audio, and have working headphones. :) Glad you found a fix. This has indeed been discussed upstream before. I can't remember the exact outcome however (or if it was specifically related to this issue or not). Your speculation is correct tho': Ultimately your h/w shouldn't be using the Speaker control when on Headphones so it's arguably a driver bug. I would hope it could be fixed at the alsa level rather than needing the fix here, but I'll have to poke some colleagues about it. While this is arguably a regression for you vs PA 1.x, the hardware/alsa driver is the thing misbehaving here, and the regression for you is a fix for others. I guess in the immediate short term, we just document this, and in the longer term, we can try and fix alsa and/or investigate whether the mute+zero option is OK for us. That's what I was thinking was the good choice in the matter. Just documenting it so if others have a similar issue, its easier for them to find the fix (this took me forever to find given its documented almost nowhere. Most people just scream to update alsa in all the documentation of an issue like this, and that doesn't solve the issue on my hardware :P). Given the fact that this fix might be a regression for others. Oddly, alsa on its own without pulse works fine so its probably more a bug in how alsa and pulse interact than it being a bug with either in particular. And I'd look into the "mute+zero" option given that its been implemented by the pulse devs before with the front volume control, as I've stated in this example thats in the file before being altered: ; On some machines Front is actually a part of the Headphone path [Element Front] switch = mute volume = zero I really wish there was more documentation on these commands as I can barely understand what they mean. Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja Keywords:
(none) =>
NEEDINFO Aye. Still a problem. Hardware:
x86_64 =>
All
Sander Lepik
2012-05-27 09:51:59 CEST
Keywords:
NEEDINFO =>
(none) Any word or update on this bug? I'm more than willing to help with fixing it, but I need to be alerted to any updates on Mageia's end regarding it. No word yet. I'm currently dealing with a massive backlog of audio stuff I'm afraid, so I've not been overly productive in that regard of late. IN theory, the "correct" place to fix it is in the kernel/alsa side such that Front does not interfere with headphones, but if this is impractical, we may have to adopt your workaround more generally. I'll need to discuss with my colleague David from Canonical as he deals with this more often than me so it would be interesting to get his take on the problem. Please look at the bottom of this mail to see whether you're the assignee of this bug, if you don't already know whether you are. If you're the assignee: We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead. If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard. Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why. Thanks :) **************************** @ the reporter and persons in the cc of this bug: If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us. @ the reporter of this bug If you didn't reply yet to a request for more information, please do so within two weeks from now. Thanks all :-D (In reply to comment #11) > No word yet. I'm currently dealing with a massive backlog of audio stuff I'm > afraid, so I've not been overly productive in that regard of late. > > IN theory, the "correct" place to fix it is in the kernel/alsa side such that > Front does not interfere with headphones, but if this is impractical, we may > have to adopt your workaround more generally. I'll need to discuss with my > colleague David from Canonical as he deals with this more often than me so it > would be interesting to get his take on the problem. Any word regarding this? My apologies I haven't been on here in some time :P It's been a busy few months. I'm comfortable with applying the fix myself for the time being as long as the fix doesn't break! It'd be interesting to know where things have gone from here. As it stands I'm about to reinstall Mageia to see if any new updates have fixed anything. I don't believe so, but if it has been fixed I'll make a reply to this comment. If not, its safe to assume its still an issue. I did speak to a few folk about it but nothing much to report yet. We're planning on meeting up in October in Denmark/Sweeden so we'll hopefully cross a few of these issues of the list then. It's also interesting times in the kernel itself and I believe kernel 3.4 changed audio parsing a bit on the kernel side so things might change a bit there. Mageia 2 will be getting kernel 3.4 soonish as it's been announced it's a long term support kernel and thus we'll benefit from that in Mageia 2. So yeah, the fix will still apply and I'm happy to continue tracking this bug until there is some direct progress. This message is a reminder that Mageia 2 is nearing its end of life. Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'. 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 Mageia version prior to Mageia 2'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 Mageia 2 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 Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. 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 Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- The Mageia Bugsquad Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 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 Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad Status:
NEW =>
RESOLVED |