Bug 928394

Could you give alsa-info.sh output (run it with --no-upload option)?
Also please attach the log of PA, too.

FYI, for obtaining a verbose log from PA, restart it on a terminal like:

  pulseaudio -k; pulseaudio -vv --log-target=file:pa.log

And save pa.log after plugging and unplugging the headphone jack.

Created attachment 632180 [details]
alsa-info.sh output

Created attachment 632182 [details]
PulseAduio log

(In reply to Foulques du Peloux from comment #3)
> Created attachment 632180 [details]
> alsa-info.sh output

You took this while you didn't plug the headphone jack, right?  If so, please give alsa-info.sh snapshot at the headphone plugged, too.

Created attachment 632183 [details]
alsa-info.sh output with heaphone plugged-in

Guess what ? The headphone is now working properly. Maybe killing the PA process did the trick.

But before this I already try to kill it and also reboot the machine and it was not working...

PA is really sensitive.  Maybe related to the phase of Venus :)
Let's keep eyes on this issue, though.

Prior to 22 April 2015 pulse audio, (front headphone jack) was functioning.

If you need assistance to test, please post message to me. My email address is open to you

reach me at
Leslie Satenstein  lsatenstein@yahoo.com

even wit today's regression, it is still not functioning,

Do you want the same three files from my system?

(In reply to Leslie Satenstein from comment #8)
> Prior to 22 April 2015 pulse audio, (front headphone jack) was functioning.
> 
> If you need assistance to test, please post message to me. My email address
> is open to you
> 
> reach me at
> Leslie Satenstein  lsatenstein@yahoo.com
> 
> even wit today's regression, it is still not functioning,
> 
> Do you want the same three files from my system?

Yes, these are essential to understand the problems.

Good Morning

I am uploading two files for you. Saturday 25April

File1 alsa-info-after.txt (with headphone plugged into the jack)

File2 alsa-info-noHdPhone.txt (headphone was removed from the jack)

Pleasenote.

Fedora 21,22 are experiencing the same issue.

I use both SUSE13.2 and Fedora21.

Created attachment 632385 [details]
Without headphones plugged

Created attachment 632386 [details]
HeadPhones Plugged into Jack

Created attachment 632387 [details]
ALSA info from a functioning HdPhoneJack This version hdphone out

Created attachment 632388 [details]
ALSA info from a functioning HdPhoneJack This version hdphone IN

SURPRISE SURPRISE

If you do not have wget installed, alsa-info.sh will overwrite itself with a NULL 

Around line 300 where tests for existence begin add .
search for and after the next line, add
#Run checks to make sure the programs we need are installed.
which wget
if [ $? !=0 ]; then
   echo "This $0 script requires prerequisite wget to be installed!"
   echo "Install it and retry."
   exit 16
fi

Do you need me to create a new bug report.

(In reply to Leslie Satenstein from comment #15)
> SURPRISE SURPRISE
> 
> If you do not have wget installed, alsa-info.sh will overwrite itself with a
> NULL 

I requested to pass --no-upload option.  This update is triggered only when no arguments are passed or --update option is passed.  It's no bug but a feature.

(In reply to Leslie Satenstein from comment #10)
> Good Morning
> 
> I am uploading two files for you. Saturday 25April
> 
> File1 alsa-info-after.txt (with headphone plugged into the jack)
> 
> File2 alsa-info-noHdPhone.txt (headphone was removed from the jack)

In both outputs, there is no change in "Headphone Jack" control value.
It means that  the driver didn't detect the headphone jack.  Most likely it's either a hardware problem or a BIOS problem.

The fact that the old PA worked was a bug.  It shouldn't have worked as you expected.  Now it gets fixed, and the problem is revealed.

That said, it's no regression but rather a "fix" to behavior correctly to the hardware that doesn't behave as expected.

> 
> Pleasenote.
> 
> Fedora 21,22 are experiencing the same issue.
> 
> I use both SUSE13.2 and Fedora21.

This implies the same consequence.

Now, what you can do is to check the real pin configuration and the hardware configuration.  Try to alsa-tools package (or hdajackretask) and see which any pin gives the jack detection corresponds to your headphone jack.  If yes, you need to reassign the headphone pin correctly, set up as a "patch" firmware to load to the driver.

If no pin reacts to the headphone jack, it's a hardware problem.  You might have connected the front panel in a wrong mode (AC97) that has a different pin assignment.

I reverted to a system that used version 5 of pulseaudio and alsa, and the headphone jack works.

Please look at the last 4 files. 

Final two show the results when the headphone jack works.
Headphone out (not plugged), Headphone IN jack and working 

To generate this for you, I reverted to a system that used versions 5 of pulseaudio and alsa.

From non-working system (pulseaudio 6 and alsa 6)
re-examine Without headphones plugged. and headphones plugged.

You have results on the same hardware.

The only thing I can do is show you the *rpm files for alsa and pulseaudio.

With the last 4 files you do have enough to go on.

Re comment 17 alsa-info.sh

If you remove or rename wget,  and run this script,
it will wipe itself out.

I submitted a bug report for it.  Fedora by default does not install wget.
Hence, testing with Fedora overwrote the script with a nullfile.

try it. rename wget  and run alsa-info.sh  (but first take a backup of the latter)

(In reply to Leslie Satenstein from comment #18)
> I reverted to a system that used version 5 of pulseaudio and alsa, and the
> headphone jack works.
> 
> Please look at the last 4 files. 
> 
> Final two show the results when the headphone jack works.

No, it doesn't "work" if your attached alsa-info.sh outputs are correct.
It's merely a bug of older PulseAudio that ignored "Front Headphone Jack" state.

> Headphone out (not plugged), Headphone IN jack and working 
>
> To generate this for you, I reverted to a system that used versions 5 of
> pulseaudio and alsa.
> 
> From non-working system (pulseaudio 6 and alsa 6)
> re-examine Without headphones plugged. and headphones plugged.

What is "alsa 6"...?  There is no such thing.
 
> You have results on the same hardware.
> 
> The only thing I can do is show you the *rpm files for alsa and pulseaudio.
> 
> With the last 4 files you do have enough to go on.

If so, again, it's a hardware problem.

Look at the state of "Front Headphone Jack" in both states.  Both showed like:

        control.43 {
		iface CARD
		name 'Front Headphone Jack'
		value false

This indicates that the headphone jack wasn't detected in the driver.
When a jack detection is provided by the driver, PulseAudio does automatic switching between the outputs per jack state.  And, the older PA didn't work well with this jack, so it *looked* as if it's working; namely, the headphone output wasn't touched.  That is, what the result was old PA was a bug of PA, and it got "fixed" by this update.

Check your hardware setup again.  There can be a BIOS setup problem.

Or, check alsa-info.sh outputs again.  If "Front Headphone Jack" state changes, then the situation is different.  The consequence here was derived just from the alsa-info.sh outputs you attached here.

(In reply to Leslie Satenstein from comment #19)
> Re comment 17 alsa-info.sh
> 
> If you remove or rename wget,  and run this script,
> it will wipe itself out.

Ah, OK, I misunderstood your description.  Then it's a clear bug.
I'll check it and fix the upstream code, too.  No need to create another bug report.

This is an autogenerated message for OBS integration:
This bug (928394) was mentioned in
https://build.opensuse.org/request/show/304258 13.2 / alsa-utils

Sometimes I have to unplug and replug my headphone to have the sound working. It was never happening before.

(In reply to Foulques du Peloux from comment #23)
> Sometimes I have to unplug and replug my headphone to have the sound
> working. It was never happening before.

This is also unlikely a regression of PA itself, but rather the flaky jack detection.  The change in PA reveals such instability because PA tries to follow the jack state more strictly.

In anyway, please get alsa-info.sh outputs at both working and non-working states.

(In reply to Takashi Iwai from comment #21)
> (In reply to Leslie Satenstein from comment #19)
> > Re comment 17 alsa-info.sh
> > 
> > If you remove or rename wget,  and run this script,
> > it will wipe itself out.
> 
> Ah, OK, I misunderstood your description.  Then it's a clear bug.
> I'll check it and fix the upstream code, too.  No need to create another bug
> report.

To make it clear: my comment here was only about alsa-info.sh script being overwritten by an empty file.  The PA behavior and headphone problem is irrelevant from the comment above.  The headphone problem is a hardware-specific issue.

(In reply to Takashi Iwai from comment #20)
> (In reply to Leslie Satenstein from comment #18)
> > I reverted to a system that used version 5 of pulseaudio and alsa, and the
> > headphone jack works.
> > 
> > Please look at the last 4 files. 
> > 
> > Final two show the results when the headphone jack works.
> 
> No, it doesn't "work" if your attached alsa-info.sh outputs are correct.
> It's merely a bug of older PulseAudio that ignored "Front Headphone Jack"
> state.
> 
> > Headphone out (not plugged), Headphone IN jack and working 
> >
> > To generate this for you, I reverted to a system that used versions 5 of
> > pulseaudio and alsa.
> > 
> > From non-working system (pulseaudio 6 and alsa 6)
> > re-examine Without headphones plugged. and headphones plugged.
> 
> What is "alsa 6"...?  There is no such thing.
>  
> > You have results on the same hardware.
> > 
> > The only thing I can do is show you the *rpm files for alsa and pulseaudio.
> > 
> > With the last 4 files you do have enough to go on.
> 
> If so, again, it's a hardware problem.
> 
> Look at the state of "Front Headphone Jack" in both states.  Both showed
> like:
> 
>         control.43 {
> 		iface CARD
> 		name 'Front Headphone Jack'
> 		value false
> 
> This indicates that the headphone jack wasn't detected in the driver.
> When a jack detection is provided by the driver, PulseAudio does automatic
> switching between the outputs per jack state.  And, the older PA didn't work
> well with this jack, so it *looked* as if it's working; namely, the
> headphone output wasn't touched.  That is, what the result was old PA was a
> bug of PA, and it got "fixed" by this update.
> 
> Check your hardware setup again.  There can be a BIOS setup problem.
> 
> Or, check alsa-info.sh outputs again.  If "Front Headphone Jack" state
> changes, then the situation is different.  The consequence here was derived
> just from the alsa-info.sh outputs you attached here.


Good morning from Montreal Canada.
My last 4 attachments show the in/out, working/nonworking  runs of alsa-info.sh
I have updates to the working pulseaudio headphone jack blocked from updates.

Updates to most recent releases of the kernel have not affected that working alsa/pulseaudio or the others. 

Comment. My main system has 5 hard disks, SUSE is on it's own as is Fedora and Windows 8.1. If the headphone jack hardware is the cause of the error, it would have impacted windows8.1.

(In reply to Leslie Satenstein from comment #26)
> My last 4 attachments show the in/out, working/nonworking  runs of
> alsa-info.sh
> I have updates to the working pulseaudio headphone jack blocked from updates.
> 
> Updates to most recent releases of the kernel have not affected that working
> alsa/pulseaudio or the others. 

Did you test "alsactl monitor" while plugging/unplugging the headphone jack, as I suggested in the previous mail?  If there is no event triggered by that, it means a hardware problem.
 
> Comment. My main system has 5 hard disks, SUSE is on it's own as is Fedora
> and Windows 8.1. If the headphone jack hardware is the cause of the error,
> it would have impacted windows8.1.

The fact that it "works" on Windows doesn't mean that there is no hardware problem.  Windows doesn't use the full feature like Linux.  We sometimes hit bugs Windows doesn't hit; sometimes because we use more chip features than Windows (the vendor never tested properly), or often BIOS is broken but Windows has a static workaround in it.

Also, Windows' behavior might be similar like bare ALSA driver, i.e. the headphone isn't muted while unplluged.  The headphone mute while unplgged is rather specific behavior of PA.

So, check whether the headhpone jack detection really works or not.  If it doesn't, accept the fact that there is something wrong in hardware or its setup (e.g. BIOS).  A driver bug is very unlikely in this regard.

Then check your BIOS setup and hardware setup.  I'll suggest another workaround once when you confirm all these.  Please report further on Bugzilla.  Thanks.

alsactl monitor 

does not indicate headphone in or transition to/from out on my desktop system..

However, executing diff between  pairs of files shows differences in some fields, which I believe may serve to indicate headphone in/out.

With desktop and headphones in, speakers remain active. 

With laptop, speakers are muted with headphones in.

(In reply to Leslie Satenstein from comment #28)
> alsactl monitor 
> 
> does not indicate headphone in or transition to/from out on my desktop
> system..
> 
> However, executing diff between  pairs of files shows differences in some
> fields, which I believe may serve to indicate headphone in/out.

The question is *which* fields changed.  Please give the diff output.  Otherwise one cannot judge.
 
> With desktop and headphones in, speakers remain active. 
 
Yeah, that's already the problem.  This should have been muted like laptop.

> With laptop, speakers are muted with headphones in.

Hi Takashi

A summary of facts.

With the new alsa versions (dated around February 1015), headphone jack sound stopped.  Testing with alsa-ctl monitor shows no signal being created with headphone in/out.

alsa-info.sh appears to show same situation as well.

I checked the bios, on this cnmputer experiencing the problem and there is no provision for audio settings. 
2 The audio is from the motherboard analog circuitry.

In checking with a different computer (Intel I3), the monitor shows in-out of the jack.

Windows 8.1 does not recognize the sound jack either. 

Question to answer
The original suse13.2 version allows sound to the front headphone jack
The Fedora21 original release does likewise

How can we revert the alsa / pulseaudio updates to 2014 versions?  Are there RPMs we can download that will allow headphone jack to work with future Linux versions? 

Do we just buy extension jacks, plug to the rear speaker jack, and continue? 

Can I revert to the preceding versions of alsa and pulseaudio that originated with suse13.2. (I have the DVD image). Is that all that has to be done, or should I re-install SUSE13.2 and block zypper from updating the alsa and pulseaudio?

OK, now it's confirmed that the jack detection really doesn't work.

Reverting back is no solution.  The root cause is that your BIOS declares that the headphone jack is detectable although apparently it's not.

Instead, a possible workaround is to override the BIOS setup in the driver level as if there is no jack detection possibility.  Try the following:

1. Create a file containing the lines below in /lib/firmware/alsa/nojack via an editor (do it as root):

[codec]
0x10ec0888 0x104382fe 0
[hint]
jack_detect = no

2. Add a module option to snd-hda-intel driver; e.g. create a file /etc/modprobe.d/50-jack.conf containing the following line (again do it as root):

options snd-hda-intel patch=alsa/nojack

3. Reload sound modules or reboot.

With this setup, the jack detection on your system is suppressed, and PA won't care about the jack detection.  You'd need to choose the output manually in the mixer setup (PA lets you choose different output routes), but it's no longer dependent on the jack status.

In the worst case, you might need to run once like
  amixer -c0 set Headphone unmute 100%

If it still doesn't work with the workaround above, please take alsa-info.sh snapshot again and upload to Bugzilla.

Created attachment 633175 [details]
The working Patch that I created from Takashi Instructions.  Thank you

The instructions written into the patch are a consolidation of your posting.
Your instructions were a-1.

Note my commments within the patch.  I believe in 1 place shopping.

I have installed it into Fedora22 beta. It works with amixer setup.

Thank you Takashi and Foulques du Peloux.  

For Foulques
Tout est bien avec Fedora22, maintenant, je le fereai en Fedora21 et SUSE13.2

Si ça marche bien on pourra fermer cette bug.

For Takashi
All works well with Fedor22. Now I will do the same installation with Fedora21 and SUSE13.2

I will report back to you. If it works, Perhaps the patch file "nojack" could be posted as part of release notes for future releases.

I would actually include the patch, but comment out the modprobe.d file line for future releases.

Back with more feedback soon.

I would like to close this issue on a positive note and to address another one.

History
With Suse13.2 vanilla download/install, headphone jack sound was on.
With some updates, headphone sound disappeared.

For Suse13.2, thanks to this bug report, I tried amixer alone, without the "nojack" patch, and sound has returned, until the next boot.

The patch works for Fedora21 and Fedora 22. 
Is there a way to permenantly link amixer to the "sound slider of Gnome?

Currently I added amixer to the .profile of SUSE and to .bash_profile of Fedora. How do I make it active at boot time so that it does not need to be in the user's profile?
  
At boot time, can we link amixer to the gnome slider and let the slider position set amixer likewise.

If you are too busy, just let me know where the slider value is stored, and I will take it from there.

Thanks again.

openSUSE-RU-2015:0822-1: An update that has one recommended fix can now be installed.

Category: recommended (moderate)
Bug References: 928394
CVE References: 
Sources used:
openSUSE 13.2 (src):    alsa-utils-1.0.28-5.3.1

Request

Is it possible to add a wrapper around this patch to respond to the following.

I use the analogue interface from the motherboard.  I apply the patch and set the sound on when I log in.  All is fine.

If by any chance I look at audio selection by looking at a second device, and upon returning to the original, The amixer settings are lost. I have therefore have to manually reset amixer.

Should this comment be presented as a new bug, or should it remain as a request? 

By the way, amixer -c0 set Headphone unmute 100%   on a line on it's own within the .profile does not always work.
I made a 2 line script amixer.sh which I placed into /usr/local/bin
 
sleep 1     
amixer -c0 set Headphone unmute 100%

within .profile the one liner
amixer.sh &


The .profile terminates before amixer settings is done and this approach has produced 100% headphone sound on reliability.

Here is another note:
On one of my test distributions, I discovered a new sound device. This was a pleasant surprise.

Headphone.

Sorry for the late reply. The main problem is still not fixed and I did some additional tests to have some more clues.

When I start my computer with the headphone plugged-in, I have no sound.
If I unplug the headphone and plug it again, this "fix" the sound. But every time I restart my computer I have to do this.

If I start my computer without the headphone and I plug it in after the desktop session is opened, sounds works properly.

In general, my speakers are always working without issue, the only problem is the headphone jack since the last update (before this alsa-utils one).

On a return from "Switch User", headphone sound is lost.

openSUSE 13.2 reached EOL.  If the issue is still reproduced in the newer distro versions like openSUSE Leap, please open a new bug report.  Thanks.