After the update to Pulseaudio 8.0 i get the below behavior. Plugging in headphones changes the Build in Analog stereo out from Line Out to Headphones. (as it should) Unplugging it makes the Build in Analog stereo out disappear and changes it to Build in Digital stereo with SPDIF as an out option. The only way to fix it -have sound again since there is nothing connected to spdif- is to change the configuration from pavucontrol Configuration > Build in Audio profile or log out and log in again in case you don't have pavucontrol installed.
That sounds like a pretty bad regression. I'll mark this as a release blocker for 9.0.
Is this something that can be fixed in a point/bugfix release or it is something more difficult to solve?
It's not obvious to me how to fix this. It might turn out to be simple or it might be complex. I don't promise to start working on this quickly (there are other important bugs on my list first), but maybe David would be interested to work on this.
Thanks for the bug report, I will need a PulseAudio verbose log to research further. Could you attach one? https://wiki.ubuntu.com/PulseAudio/Log Please both plug and unplug headphones while the log is active. Thanks!
Created attachment 121383 [details] log file Not sure the method on the link gives the results you would expect but here goes.
(In reply to Apostolos B. from comment #5) > Created attachment 121383 [details] > log file > > Not sure the method on the link gives the results you would expect but here > goes. No, apparently pulseaudio either failed to kill or respawned for some reason. Not sure how ARCH spawns pulseaudio, but make sure pulseaudio is not running before starting the log. Thanks!
This should stop pulseaudio and prevent respawns on Arch: systemctl --user stop pulseaudio.socket pulseaudio.service To restore the system back to normal functioning, run this: systemctl --user start pulseaudio.socket
Created attachment 121389 [details] correct log That will do it i believe.
( 0.178| 0.000) D: [pulseaudio] module-alsa-card.c: Jack 'Line Out Front Jack' is now unplugged ( 0.178| 0.000) D: [pulseaudio] module-alsa-card.c: Jack 'Line Out CLFE Jack' is now unplugged ( 0.178| 0.000) D: [pulseaudio] module-alsa-card.c: Jack 'Line Out Surround Jack' is now unplugged ( 0.178| 0.000) D: [pulseaudio] module-alsa-card.c: Jack 'Front Headphone Jack' is now unplugged Since your line-out jack (the front/main one) is unplugged, I believe we're doing the right thing by switching to something else (i e, in your case the digital output, for which do not know the jack status). Do you actually have something plugged into your line out jack, or why do you want analog line out to be selected?
I have nothing connected true but if i unplug and plug the headphones again it stays to the digital out (which also has nothing connected to it) and i have no sound on the headphones.
Ah, so the problem is that it does not switch to headphones rather than it switches from them; although this happened to be less of a problem in earlier versions because it stayed on the same profile. I'm going to attach a patch now, can you test it? And if it does not work, could you submit another pulseaudio log which also includes you plugging in headphones while on the digital profile? Thanks!
Created attachment 121395 [details] [review] Routing change patch
(In reply to David Henningsson from comment #12) > Created attachment 121395 [details] [review] [review] > Routing change patch This patch fixes the issue for me. Tested-by: Nick Sarnie <commendsarnex@gmail.com>
Can you please note my bug report filed here: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1521987 ? It is supposedly about the same problem, and I've produced a lot of logs and description of how the problem works.
@David I can't test right now on the system i get the bug (its my stable one) and on my other system i don't have HW (digital out) to test. @sarnes reported it fixed his issue (assuming it was the same as mine) so it believe it works. Maybe others can chime in.
*** Bug 93986 has been marked as a duplicate of this bug. ***
The patch (Routing change patch) https://bugs.freedesktop.org/attachment.cgi?id=121395 fixes the problem (at least for my reported bug: sorry for the duplicate...)
The fix is now in master.
*** Bug 96237 has been marked as a duplicate of this bug. ***
Just to let you know: I had a similar bug with Fedora 24 which drove me nuts. Analog output was always switched back to digital, losing sound. Changing it in pavucontrol didn't last longer than a few seconds. With the patch from comment 12, my problem is fixed!
I am not sure that the suggested patch is a good fix for the problem. As I understand it, with the patch, when the currently active destination becomes unavailable, new destination is chosen on the basis of its priority. Now consider my own use case: I have S/PDIF and Analog outputs on the chip, but S/PDIF is not connected to anywhere (there is no connector on the box). I have speakers permanently connected to the analog "line out" socket. And I use headphones intermittently. Normally, desktop's audio widget configures "line out" as active, which is what I want. When I plug the headphones, they automatically become active, and speakers are muted, which is what I want, again. But, when I unplug the headphones, (unconnected) S/PDIF becomes active instead of the speakers, and I lose sound until I manually reconfigure the output via the audio widget. I think that my scenario is quite typical (it happens both on my desktop and notebook computers), and should be addressed better. Thank you.
I believe PulseAudio 9.0 will handle your use case well. Please report back if it doesn't.
(In reply to Tanu Kaskinen from comment #22) > I believe PulseAudio 9.0 will handle your use case well. Please report back > if it doesn't. It does not. Version: 1:9.0-2ubuntu2 Same behavior: after plugging and unplugging the headset some nonexistent device becomes active, and I have no sound until I manually select "line out".
Do you happen to have the audio settings application open? If you do, it can mess up the device selection: https://bugzilla.gnome.org/show_bug.cgi?id=762932
(In reply to Tanu Kaskinen from comment #24) > Do you happen to have the audio settings application open? If you do, it can > mess up the device selection: > https://bugzilla.gnome.org/show_bug.cgi?id=762932 It happens when audio control application running and not running likewise, but desktop's audio widget in the panel is indeed running (Cinnamon and Unity, same manifestations). It is possible that this audio widget is indeed the culprit.
(In reply to Eugene Crosser from comment #25) > It happens when audio control application running and not running likewise, > but desktop's audio widget in the panel is indeed running (Cinnamon and > Unity, same manifestations). It is possible that this audio widget is indeed > the culprit. It's possible, but I don't think it's likely. Can you attach a log file that shows what happens when you start with analog output selected and headphones plugged in, and then unplug them and plug them back in? Instructions for getting the log: https://wiki.ubuntu.com/PulseAudio/Log
Created attachment 128797 [details] Pulse Log incorrect switching Log that should show pulse incorrectly switching to digital when it should switch back to the previous configuration for speakers.
In my case speakers should be set to Analog Surround 5.1 Output + Analog Stereo Input, however after unplugging headphones they are switched to digital out.
The log doesn't match your problem description. The digital profile is not activated at all. The log shows switching between headphones and lineout in 2.1 mode. You wanted to use 5.1, so is your problem actually that you get 2.1 audio instead of 5.1?
Created attachment 128999 [details] digital/5.1 - stereo out/digital Sorry, this bug isn't consistent so that last log may not have reflected the issue. This _should_ show that it starts my headphones as digital out, upon unplugging the line out should be switched to 5.1. Again plugging in headphones changes the output to digital. After setting the headphones to stereo out via pulse audio volume control, unplugging the headphones sets the configuration back to digital.
Thanks, the log is interesting. At line 5943 the headphones are plugged in. Pulseaudio then decides to switch from the 5.1 profile to the analog stereo profile, as expected. After switching the profile, however, pulseaudio decides to immediately switch to digital output instead. Unfortunately the log doesn't show why this happens. If I write a patch that adds better logging, will you be able to apply and test it? Here are some instructions for building and installing pulseaudio from source: https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/PulseAudioFromGit/
Sure, if you write a patch I will compile and test it.
Created attachment 129175 [details] [review] 0001-card-log-the-reason-for-profile-changes.patch Here's the patch. It's written against the git master branch. If you need it for some other PulseAudio version, let me know and I'll rebase it.
Created attachment 129184 [details] pulse verbose log with 0001-card-log-the-reason-for-profile-changes.patch So interestingly enough I can't reproduce the issue using git master. Attached are two logs as one attachment. The second log starts at line 5308 (Didn't want to spam attachments). The first log shows pulse crashing upon disconnecting the headphones. The second log shows pulse switching between 5.1-stereo and Analog Stereo working fine. If you rebase the patch on 10.0 I can try it again to see what was going on. Version 10.0 is the current version from Arch Linux's repos. I assume a commit since then must have fixed something either intentionally or unintentionally.
(In reply to flat from comment #34) > Created attachment 129184 [details] > pulse verbose log with 0001-card-log-the-reason-for-profile-changes.patch > > So interestingly enough I can't reproduce the issue using git master. The first log with the crash shows a switch to the digital profile. Unfortunately, the crash happens before the log message I added is printed. The first log shows four "audio-volume-change" sounds being played in quick succession during the crash. The volume changes are initiated by gnome-settings-daemon. Did you change the volume manually while disconnecting the headphones, or is this something that gnome-settings-daemon does automatically? > Attached are two logs as one attachment. The second log starts at line 5308 > (Didn't want to spam attachments). The first log shows pulse crashing upon > disconnecting the headphones. The second log shows pulse switching between > 5.1-stereo and Analog Stereo working fine. If you rebase the patch on 10.0 I > can try it again to see what was going on. Version 10.0 is the current > version from Arch Linux's repos. I assume a commit since then must have > fixed something either intentionally or unintentionally. I don't think it's fixed in master, but I can anyway make a patch for 10.0. I'll change it so that the profile change reason is printed in an earlier phase. I'll also add some logging in an attempt to make it easier to track down the reason for the crash if it happens again.
Created attachment 129226 [details] [review] 0001-card-log-the-reason-for-profile-changes.patch (for 10.0) Here's the updated patch.
Created attachment 129265 [details] pulse audio verbose log with 0001-card-log-the-reason-for-profile-changes.patch 10.0 Here is the log from the new rebased patch. The bug did occur in git master but not as often. >The first log shows four "audio-volume-change" sounds being played in quick >succession during the crash. The volume changes are initiated by gnome-settings-daemon. >Did you change the volume manually while disconnecting the headphones, or is this something that gnome-settings-daemon does automatically? I'm not sure if that was me or not. I usually tap the volume key a couple times to see what output configuration it is set on because it's quick. This time I didn't touch the volume manually. The log should show it switching from 5.1 to digital then digital to 5.1 and then 5.1 to stereo duplex and then stereo duplex to digital.
The new log doesn't seem to have the patch applied. Can you try again? You can check that pulseaudio is running with the patch by searching the log for messages that contain "XXX" that are printed whenever the card profile changes.
Created attachment 129322 [details] pulse audio verbose log with 0001-card-log-the-reason-for-profile-changes.patch 10.0 Sorry it took a couple days for it to happen again. Guess it helps when you compile to actually apply the patch... haha. Here's a log from it switching between digital and normal, even after I set it to the correct configurations it seems to switch. Looking through the log I think it might have to do with budgie-panel, but I'm not sure. Also got another crash so that's the first log. Second log starts on line 4424
Same issue on xfce4, so it's not budgie.
Sorry for the long delay, I have trouble keeping up with all email... (In reply to flat from comment #39) > Created attachment 129322 [details] > pulse audio verbose log with > 0001-card-log-the-reason-for-profile-changes.patch 10.0 > > Sorry it took a couple days for it to happen again. Guess it helps when you > compile to actually apply the patch... haha. Here's a log from it switching > between digital and normal, even after I set it to the correct > configurations it seems to switch. Looking through the log I think it might > have to do with budgie-panel, but I'm not sure. Yes, "Budgie Volume Control" changes the profile to digital. > Also got another crash so > that's the first log. Second log starts on line 4424 It's not a crash, it's a failure to start the daemon. module-esound-protocol-unix can't setup itself, because the socket it needs is reserved by some other process (probably another pulseaudio instance). I'm not sure why this happens, but you can safely remove module-esound-protocol-unix from /etc/pulse/default.pa. It's extremely unlikely that you have any applications that still use esound.
(In reply to flat from comment #40) > Same issue on xfce4, so it's not budgie. It certainly was Budgie according to the log. Maybe xfce4 has a similar bug in its volume control thingy.
(In reply to Tanu Kaskinen from comment #42) > (In reply to flat from comment #40) > > Same issue on xfce4, so it's not budgie. > > It certainly was Budgie according to the log. Maybe xfce4 has a similar bug > in its volume control thingy. No problem on the delay, thanks for taking the time to look into this. I'll file a bug report with budgie.
Created attachment 131569 [details] pulse audio verbose log Same problem and use case: analog line-out speakers, headphone plugged-in, headphone unplugged, digital output profile set instead of analog line-out (Analog Duplex to be precise). It happens on Fedora 25 (10.0-2.fc25) and openSUSE tumbleweed (can't have access to that PC right now), both running KDE Plasma desktop (5.9.5). KDE devs said it should be reported here [https://bugs.kde.org/show_bug.cgi?id=380316#add_comment]
(In reply to pablow.1422 from comment #44) > Created attachment 131569 [details] > pulse audio verbose log > > Same problem and use case: analog line-out speakers, headphone plugged-in, > headphone unplugged, digital output profile set instead of analog line-out > (Analog Duplex to be precise). > > It happens on Fedora 25 (10.0-2.fc25) and openSUSE tumbleweed (can't have > access to that PC right now), both running KDE Plasma desktop (5.9.5). > > KDE devs said it should be reported here > [https://bugs.kde.org/show_bug.cgi?id=380316#add_comment] Never mind. Something in the miniplug speaker contact was preventing the detection of the port as being connected. Sorry for the useless reply.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/390.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.