Description of problem: This issue occurs in combination of Pulseaudio with Phonon (it does not occur when using alsa alone to manage audio with phonon). Whenever headphone's are plugged into the headphone jack headphone audio is muted/near inaudible and the output device in Phonon is switched from "Speaker" to "Headphone". Note that audio remains muted on the speakers when headphones are unplugged until the volume is adjusted. There exists a fix that must be constantly applied each time the headphones are plugged in by switching the output from headphone back to speaker in Phonon settings, then adjusting the volume (in the system or application. In my case, Amarok.). The issue will not occur if pulseaudio is disabled in the control center, and alsa is allowed to manage audio. To note, even with output changed from headphone to speaker in phonon, the main speakers will pleasantly remain muted when headphones are plugged in. This leads me to believe my audio hardware may have a hardware switch muting the main speakers, and pulseaudio is muting an improper channel. (This occured in Kubuntu where the speaker volume output in alsa controlled both headphones and main speakers. Pulseaudio was attempting to always mute the speaker output regardless when headphones were plugged in. This resulted in no audio output to very little.) If needed, I can run any commands neccessary to give more hardware information about my system. Version-Release number of selected component (if applicable): Mageia RC2, fully updated. Problem existed both before and after update. How reproducible: Constantly Steps to Reproduce: 1. Log in 2. Play audio-Note it works through speakers 3. Plug in headphones- audio completely inaudible through either speakers or headphones 4. Unplug headphones, audio still inaudible until volume adjusted (leading me to believe a channel may be being muted that shouldn't be)
Additional Information: The unit in question is a Asus G73SW Laptop with a realtek soundcard using the Intel HDA Driver.
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 PackagesSource RPM: (none) => pulseaudio
(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.
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 => AllVersion: Cauldron => 2
Keywords: NEEDINFO => (none)CC: (none) => sander.lepik
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 => RESOLVEDResolution: (none) => OLD