Bug 16039

I should have asked you which DE you used before testing in a fresh install :-(

It works fine here with a HDA intel (ICH9 Family) sound card, both in 4alpha (or 4beta) KDE traditional 64bit install that has been kept up-to-date as cauldon since, and in a pre-5final KDE traditional 64bit install.

From IRC I know your card is:
snd_hda_intel   : Intel Corporation|82801JD/DO (ICH10 Family) HD Audio Controller [MULTIMEDIA_AUDIO_DEV] (vendor:8086 device:3a6e subv:1028 subd:027f) (rev: 02)

And you're using Mate.

@ diogenese
Was it you who reproduced the issue? If so, do you have soundcard or DE in common with saptech?

CC: (none) => marja11, warrendiogenese

(In reply to Marja van Waes from comment #1)
> @ diogenese
> Was it you who reproduced the issue? If so, do you have soundcard or DE in
> common with saptech?

Yes, when he mentioned this in #mageia, I dug up a set of headphones and plugged them into the front panel. No sound in the headphones and speakers kept playing.

It's the first time I've used the front panel jack, so not entirely sure it was working beforehand. I also tried the front panel mic jack that's right next to it and it does work.

(In reply to Marja van Waes from comment #1)
> I should have asked you which DE you used before testing in a fresh install
> :-(
> 
> It works fine here with a HDA intel (ICH9 Family) sound card, both in 4alpha
> (or 4beta) KDE traditional 64bit install that has been kept up-to-date as
> cauldon since, and in a pre-5final KDE traditional 64bit install.
> 
> From IRC I know your card is:
> snd_hda_intel   : Intel Corporation|82801JD/DO (ICH10 Family) HD Audio
> Controller [MULTIMEDIA_AUDIO_DEV] (vendor:8086 device:3a6e subv:1028
> subd:027f) (rev: 02)
> 
> And you're using Mate.
> 
> @ diogenese
> Was it you who reproduced the issue? If so, do you have soundcard or DE in
> common with saptech?

I'm using Mate 1.8 and I believe diogenese is using the same sound card and DE also. We both used the boot.iso to install. It may be something with sound that is missing for us. What it could be, I have no idea.

This is unrelated to DE. It's either a kernel or pulseaudio auto profile bug. We'd need a "pacmd ls" both before you plug in a jack and after it's plugged in to see if PA is aware of the port and whether it can track the jack status.

Created attachment 6640 [details]
Stephen pacmd_ls before

I entered the commands as user, not root.

Created attachment 6641 [details]
Stephen pacmd_ls after

Again as user, not root...I wasn't sure how to attach both together.

Thanks - attaching separately is perfect (as is doing it as a user).

This correctly shows PA switching ports: the Sink port changes from analog-output-speaker to analog-output-headphones after plugging in the headphones. The volume also changes appropriately (we store volumes separately for these paths).

So something at the alsa level mustn't be working properly.

Could you therefore supply "amixer -c 0" output before and after the plug too?

Created attachment 6642 [details]
amixer_before

Here is amixer before

Created attachment 6643 [details]
amixer_after

amixer after

OK, so this is interesting, it seems the "Headphones" path goes on but "Speaker" path doesn't go off (when you plugin the headphones).

Two interesting settings also show up here:

"Auto-Mute Mode" and "Independent HP". Now I believe the auto-mute mode is only for mic input when using built-in mic and output is via speakers. I would try flipping the latter setting to see if it helps.

amixer -c 0 set "Independent HP" Enabled

See if that helps, if not, flip it back to Disabled again.

Ultimately, if you know it works on Arch, then getting the amixer output (and pacmd output) there both unplugged and plugged would be a useful comparison.

Hope this gets some way closer to a solution.

I had to run the command without the quotes around "Independent HP" otherwise I get 'amixer: Invalid Command' msg. 

[saptech@localhost ~]$ amixer -c 0 set Independent HP enabled
amixer: Unable to find simple control 'Independent',0


I'll have to boot into Arch and get the amixer & pacmd output for you.

Thnx.

Created attachment 6648 [details]
Archlinux before

Created attachment 6649 [details]
Archlinux after

(In reply to Stephen Pettin from comment #11)
> I had to run the command without the quotes around "Independent HP"
> otherwise I get 'amixer: Invalid Command' msg. 
> 
> [saptech@localhost ~]$ amixer -c 0 set Independent HP enabled
> amixer: Unable to find simple control 'Independent',0

You need the quotes, they are important!

Also the last argument should be Enabled, not enabled. Perhaps that works better?

That said, I don't think this is important :)

Looking at the Arch output, what's interesting is that your Speaker is not actually used.

Try this:

amixer -c 0 set "Auto-Mute Mode" "Line Out+Speaker"

This, plus the fact that the "speakers are not being used at all on Arch is the only real difference. So let's start with the above and we can move on to trying the speaker differences after.

Just out of curiosity, this *is* a laptop with a built in speaker right? Or do you have something plugged into line out at the back?

Created attachment 6650 [details]
pacmd ls before

Created attachment 6651 [details]
pacmd ls after

Typing it with the quotes would give Invalid Command, same if I typed Enabled. That's why I tried it without the quotes and capital E.

Sorry if I didn't mention it, it's a Dell Optiplex 760 desktop system, quadcore. I do have external speakers plugged into the back speaker port.

Here is the output of 

$ amixer -c 0 set "Auto-Mute Mode" "Line Out+Speaker"
Simple mixer control 'Auto-Mute Mode',0
  Capabilities: enum
  Items: 'Disabled' 'Speaker Only' 'Line Out+Speaker'
  Item0: 'Line Out+Speaker'

When I typed the above command, nothing from headphones, and now nothing from the speakers while the headphones are plugged in. Before, I was getting sounds from the speaker but barely could hear it.

We need to find out if others who installed using the boot.iso are having this issue with headphones. I'll ask around in the IRC channel, I'm known there as saptech.

Thnx.

(In reply to Stephen Pettin from comment #18)
> We need to find out if others who installed using the boot.iso are having
> this issue with headphones. I'll ask around in the IRC channel, I'm known
> there as saptech.

This definitely is unrelated to boot.iso. It's a totally different part of the stack.

I installed Mga4 kernel, kernel-desktop-3.14.43-1.mga4-1-1.mga4 and booted into it, and the headphones work. Thnx to other people in the IRC channel.

When I opened alsamixer, Master/Headphones/Speaker/PCM were all muted while a song was playing. I unmuted them all after plugging in the headphones. After I unplug the headphones, only Headphone show muted. I think that's how it should work.

I think using mga5 kernel, alsamixer show a difference for those sliders. I would have to reboot to check.

Created attachment 6652 [details]
Mga4 Kernel before amixer

Created attachment 6653 [details]
Mga4 Kernel after amixer

This is not a release blocker since I assume most people will not use the boot.iso, which I used for my current install. I'm not sure how many others who have used the boot.iso are having this issue.

(In reply to Stephen Pettin from comment #23)
> This is not a release blocker since I assume most people will not use the
> boot.iso, which I used for my current install. I'm not sure how many others
> who have used the boot.iso are having this issue.

As Colin said in comment 19, this bug is not related to using boot.iso. The installation media can at most impact which packages are present on your system.

If we can describe is precisely enough and we think it can happen to lots of users, could someone write an Errata entry (without a reference to boot.iso, which is not a cause of the bug)? Otherwise just remove FOR_ERRATA from the whiteboard.

Whiteboard: (none) => FOR_ERRATA MGA5TOO

Audio h/w is so different that it doesn't really make sense to me to include it in an Errata.

Ok, thanks.

Whiteboard: FOR_ERRATA MGA5TOO => MGA5TOO

I noticed the same symptom.  Will test further.

CC: (none) => laidlaws

Same in Windows.  Probably forgot a plug inside the box.  Darn!

No one reported still seeing this issue (other than a real hardware issue with the same syptoms) since 21 months ago.

@ Stephen

Is it still valid? If so, only in Mageia 5, or also in cauldron?

Keywords: (none) => NEEDINFO

Mine was a hardware problem.  Old case was wired for AC97, and new mobo was set up for Intel standard.  Bought a new case, and it was cured.

(In reply to Doug Laidlaw from comment #31)
> Mine was a hardware problem.  Old case was wired for AC97, and new mobo was
> set up for Intel standard.  Bought a new case, and it was cured.

Thanks for the reply, Doug.

Stephen and William didn't/couldn't reply and haven't commented in this report since June 2015.... I think in their case it wasn't a hardware issue, so not closing as invalid, but closing as old.

Status: NEW => RESOLVED
Resolution: (none) => OLD

OK.  I am used to the boom-box arrangement, where there is a hardware switch built into the phone socket, that disconnects the speakers.