My guess is that this is interference from the gdm PulseAudio instance. I've experienced that myself. If you kill gdm's PulseAudio, does the problem go away?

http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa/mixer/paths/analog-output-speaker.conf?id=22aac4e9fdb3786178f7815a0cb2150f588b1582

Do pulseaudio really need to change headphone volume to off when switch to speake?

(In reply to Tanu Kaskinen from comment #1)
> My guess is that this is interference from the gdm PulseAudio instance. I've
> experienced that myself. If you kill gdm's PulseAudio, does the problem go
> away?

I did:

1) restart
2) grepped ps for pulseaudio
3) killed the instance not belonging to my user id with -9
4) grepped again and saw that it was restarted
5) after that volume no longer gets reset and the volume state gets remembered separately for headphone connected/disconnected state as I expected.

(In reply to Raymond from comment #2)
> Do pulseaudio really need to change headphone volume to off when switch to
> speake?

In my opinion it's good to allow manual switching between headphones and speakers when headphones are plugged in, and playing to both outputs at the same time is not a good idea.

(In reply to Christoph Reiter from comment #3)
> I did:
> 
> 1) restart
> 2) grepped ps for pulseaudio
> 3) killed the instance not belonging to my user id with -9
> 4) grepped again and saw that it was restarted
> 5) after that volume no longer gets reset and the volume state gets
> remembered separately for headphone connected/disconnected state as I
> expected.

Ok, I didn't expect the automatic restart, but I guess gdm keeps reconnecting to pulseaudio after disconnection just like normal user sessions do (and trying to connect to pulseaudio while it's not running triggers autospawning).

When a session is inactive (like the gdm session is inactive during your own login session) udev removes sound card access for the inactive user. The reason why gdm nevertheless is able to interfere with the active session is that once pulseaudio opens the sound card mixer, it keeps the connection open. When udev changes the mixer device permissions, that doesn't affect existing mixer connections.

The fix is to close the mixer connection when PulseAudio detects that it lost permissions to the sound card. I started working on that a while ago, but then I got something else to do...

If switch is already muted, there is no point to change volume control to zero dB(maximum) nor Off (minimum)

Do pulseaudio store headphone volume and restore the user selected level after restart/reboot

 

 [Element Headphone]
-switch = mute
-volume = zero
+switch = off
+volume = off

(In reply to Raymond from comment #5)
> 
> If switch is already muted, there is no point to change volume control to
> zero dB(maximum) nor Off (minimum)

It also doesn't hurt. And in theory there could be a volume element without a switch element, in which case the volume matters.

> Do pulseaudio store headphone volume and restore the user selected level
> after restart/reboot

Yes.

(In reply to Tanu Kaskinen from comment #6)
> (In reply to Raymond from comment #5)
> > 
> > If switch is already muted, there is no point to change volume control to
> > zero dB(maximum) nor Off (minimum)
> 
> It also doesn't hurt. And in theory there could be a volume element without
> a switch element, in which case the volume matters.


If the headphone is already unpluged, do pulseaudio really need to mute HP playback switch or turn HP volume off.  


> 
> > Do pulseaudio store headphone volume and restore the user selected level
> > after restart/reboot
> 
> Yes.

Can the user dump database to verify pulseaudio had store the headphone and speaker volume? 

eg. User want to set hp to 50% and speaker at 75%

(In reply to Raymond from comment #7)
> (In reply to Tanu Kaskinen from comment #6)
> > (In reply to Raymond from comment #5)
> > > 
> > > If switch is already muted, there is no point to change volume control to
> > > zero dB(maximum) nor Off (minimum)
> > 
> > It also doesn't hurt. And in theory there could be a volume element without
> > a switch element, in which case the volume matters.
> 
> 
> If the headphone is already unpluged, do pulseaudio really need to mute HP
> playback switch or turn HP volume off.  

The Headphone element is not the only element that affects headphone volume. If the Master element is at high level prior to plugging in headphones, and the to-be-restored volume for headphones is low, there will be a spike in the volume if the headphones are not muted, because the Master volume is initially too high.

> > > Do pulseaudio store headphone volume and restore the user selected level
> > > after restart/reboot
> > 
> > Yes.
> 
> Can the user dump database to verify pulseaudio had store the headphone and
> speaker volume? 
> 
> eg. User want to set hp to 50% and speaker at 75%

We don't have native tools for dumping the database contents. Pulseaudio supports three different database formats, the format is decided during building. The "tdb" and "gdbm" formats probably have some tools for examining the database contents. The "simple" format is homegrown, and doesn't have tools for dumping the database contents.

The database is the file with "device-volumes" in its name under ~/.config/pulse, if you want to take a look.

Can you post the output of alsa-info.sh

Previous alsa driver only has one master playback volume and switch,  there is thinklpad-acpi for the mute button

There is no mute cap in pin complex,  only at audio output


https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1072146

The driver got speaker and headphone playback volume after using auto generic parser

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=a555bb8c6bf6932c5706745bfdbad22df26324d9



There was patch for changing thinkpad acpi for mute led which bind mute button to virtual master

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/thinkpad_helper.c?id=b317b032d2dcb5e518cc9630cc6f1c7c24afedfc

If the volume up and volume down key change virtual master volume,  speaker volume and headphone will be still the same as they are slaves of virtual master

Raymond, the root cause was already established. There's nothing more to debug.

Marking as a 9.0 release blocker.

Raymond, there must be some deeper problem, because on my machine two pulseaudio instances cause race condition, and I got random audio balance level for headphones. What do you think?

Please, tell me where can i get the solution for this issue? I am experiencing this issue. Should i write this post everyday to get some respond?


Pulseaudio 8.0
Kernel 4.4.1
GDM 3.18.2

Discription: plug/unplug jack audio connector cause random headphone level everytime

Desire: to solve the issue

Real picture: open source commnunity does not provide suitable way of contributing

(In reply to Sergei Sinyak from comment #14)
> Please, tell me where can i get the solution for this issue? I am
> experiencing this issue. Should i write this post everyday to get some
> respond?

So you are pissed off when nobody answers your question within 19 hours? You have some high expectations...

Assuming that it's gdm that starts the other pulseaudio instance, here are instructions for disabling pulseaudio for gdm: https://www.debuntu.org/how-to-disable-pulseaudio-and-sound-in-gdm/

> Real picture: open source commnunity does not provide suitable way of
> contributing

What do you want to contribute?

(In reply to Tanu Kaskinen from comment #15)
> So you are pissed off when nobody answers your question within 19 hours? You
> have some high expectations...

I am asking you to forgive me, please. Sorry for not being patient.

> 
> Assuming that it's gdm that starts the other pulseaudio instance, here are
> instructions for disabling pulseaudio for gdm:
> https://www.debuntu.org/how-to-disable-pulseaudio-and-sound-in-gdm/
> 
> > Real picture: open source commnunity does not provide suitable way of
> > contributing
> 
> What do you want to contribute?

I'd like to code in C/C++ for practice. The real idea is to contribute to open source projects. I tried to study radeon module sources previous summer, but it went nowhere. Maybe it was really hard task to start with.

The actual goal was to understand what really happens, which program actually goes wrong way. That solution from debuntu.org is not required. I've seen that.

I would pleased, if you can provide some links where i can study work of server. Actually about processing plug/unplug events. Because as i see it is about incorrect work of gdm too.

Yet once, please sorry for irritating you.

(In reply to Sergei Sinyak from comment #16)
> I am asking you to forgive me, please. Sorry for not being patient.

You're forgiven :)

> I'd like to code in C/C++ for practice. The real idea is to contribute to
> open source projects. I tried to study radeon module sources previous
> summer, but it went nowhere. Maybe it was really hard task to start with.
> 
> The actual goal was to understand what really happens, which program
> actually goes wrong way. That solution from debuntu.org is not required.
> I've seen that.
> 
> I would pleased, if you can provide some links where i can study work of
> server. Actually about processing plug/unplug events. Because as i see it is
> about incorrect work of gdm too.

There isn't much high-level documentation for the server implementation. The wiki has some very incomplete and old notes that I wrote when I was new to PulseAudio (the wiki seems down at the moment, so I can't give a link), and more recently Ahmed Darwish wrote down his own notes here: https://a-darwish.gitbooks.io/diary-of-pulseaudio-developement/content/

In any case, feel free to ping me in #pulseaudio in irc (nick: tanuk) when you have questions about the code. I'm in the channel 24/7, so I'll see your message regarless of when you send it, but obviously I can't always react immediately.

About how to fix this bug:

gdm does nothing wrong, this same issue exists also when having two users logged in simultaneously (one active, one inactive).

The root cause of this bug is that plugging in headphones causes the inactive user's pulseaudio to change the sink port, and when the port is changed, the inactive user's pulseaudio also sets the sink volume to what it thinks is appropriate for headphones. The inactive user's pulseaudio shouldn't touch the volume while the user is inactive. It would be easy to block mixer changes while inactive, but it's more complicated to figure out how to restore the mixer correctly when the user becomes active again.

I think the proper fix is to unload the module-alsa-card instance when udev revokes the user's access to the card (which happens when the user becomes inactive). When the user gets access again, the card should be loaded again and its state should be restored to what it was when the user lost access. However, I'm pretty sure that we don't currently restore everything properly (for example, if the default sink was on the unloaded card, I don't think we set the default sink to the card when it's loaded again). With many unknowns, I'm not confident that I can implement this solution before 9.0.

A simpler fix/workaround might be to modify module-switch-on-port-available so that it doesn't do any port/profile switching when the user is inactive. module-switch-on-port-available is the module that does the decision to switch from speakers to headphones when headphones are plugged in. module-switch-on-port-available could collect a queue of unhandled events while the user is inactive, and process the queue when the user becomes active - that should restore the mixer to an appropriate state.

Note that I plan to fix this before we start preparing the 9.0 release (code freeze is planned for 2016-04-21, so that's my deadline). There are a couple of other bugs that I'll work on first, though, so if you think you can fix this before me, that would of course be very welcome. But if you prefer to fix something else, you can have a look at the list of bugs that should be relatively easy to fix: https://bugs.freedesktop.org/buglist.cgi?quicksearch=product%3Apulseaudio%20keyword%3Alove&list_id=569621

Starting with an easier bug may be a better way to get yourself familiar with the code base, but of course it's more motivating to work on a bug that you suffer yourself.

I seem to have a similar and maybe the exact same issue with 8,0. I'd like to contribute some more information that hasn't been given so far and also a fix for those experiencing the problem.

In my case when jacking in or out a headphone the sound is completely gone from my system. Maybe some volume is set to zero which I cannot raise/see using my Plasma (KDE) Audio Volume applet or keyboard volume keys. Jacking in/out again doesn't solve the issue.

I thought it could be a problem with my sound card driver because I can't play sounds even when setting other backends (not pulseaudio) on other applications (like VLC) but I found that running:

pulseaudio --kill
pulseaudio --start

solves the problem so even if it is a driver issue it's likely that pulseaudio is responsible somehow.

I agree this should be a priority/release blocker. The user shouldn't be "punished" with jacking in/out headphones by having to reset the service (or entire system if they don't know about the easier fix!) and this absolutely wasn't happening before the new version hit Debian testing.

Let me know if I should open another bug for this even though it's similar or how I can help to test the issue. Thanks for the great work on pulseaudio - I can't explain it but the first time I installed it on Linux to try out some audio hacks the system instantly had much higher quality audio and I was honestly surprised! (let me know if anyone has an idea of how that was even possible :D)

Alex, your issue looks like something different. I would guess it's one of these:
https://bugs.freedesktop.org/show_bug.cgi?id=93903
https://bugs.freedesktop.org/show_bug.cgi?id=93946

Created attachment 123437 [details] [review]
[PATCH] alsa: ignore jack events when the user is inactive

I wrote a fix some time ago, but I haven't had time to properly test it yet. I'll attach it here in case someone else wants to test it. I can't unfortunately reproduce the bug on my machine any more for some reason.

The patch should prevent inactive users from changing the mixer settings. The patch will probably also mess up the jack detection state a bit for inactive users, so if an user becomes inactive while headphones are plugged in, and another user unplugs the headphones, the first user's pulseaudio will think the headphones are still plugged in when the first user becomes active again. I think that's not too serious compared to the current situation.

Created attachment 123563 [details] [review]
alsa: Reread and upate jack status when a card is unsuspended

This is needed so we don't keep stale jack availability information
while the card is suspended.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=93259
Signed-off-by: Arun Raghavan <arun@arunraghavan.net>

I've now pushed out the fixes for this.