Description of problem: After yum update (except kernel), pulseaudio didn't start when I logged into Xfce desktop session. I checked the session/startup settings and pulseaudio is checked. Version-Release number of selected component (if applicable): pulseaudio-module-x11-6.0-2.fc21.x86_64 How reproducible: always since update Steps to Reproduce: 1. update F21 to April 05 2015 2. login to Xfce session 3. Actual results: No sound, pulseaudio is not started Expected results: pulseaudio should be started. Additional info: running 'pulseaudio --start' after login, fixes the problem, AFAIKT. I didn't try running start-pulseaudio-x11, which is what the session does, I think. I don't know why the results are different.
Nothing at all has changed with xfce4-session in f21 since last october. ;) Also, Xfce should start pulseaudio on login if it's installed no matter what your session settings have. Also, if it's not running and you run some audio application it should start it. So, some questions: 1. When did it last work as expected? 2. What changed since then? check /var/log/yum.log ? Perhaps this bug should go against pulseaudio... particularly if it was updated?
(In reply to Kevin Fenzi from comment #1) > Also, Xfce should start pulseaudio on login if it's installed no matter what > your session settings have. Okay, but that's very confusing. Why would that be? how does it do that if it's not part of the session startup? > Also, if it's not running and you run some audio application it should start it. That may be the case, I haven't really noticed. But, xkb-bell doesn't work until it's already running and x11 module has been loaded. So, most of my audio cues are broken unless it's started immediately. > So, some questions: > > 1. When did it last work as expected? As I said, it worked two weeks ago when I last rebooted, AFAIK. But, I think it is likely this has been a problem for longer. Given your statement about PA starting "on-access", I bet this has been happening since I upgraded to F21, at least. > 2. What changed since then? check /var/log/yum.log ? I updated with yum yesterday and pulseaudio pkgs were included in that. pulseaudio is now 6.0-2. Wow, it looks like it was a full major revision before this update, 5.0-25...in the middle of F21; that's unusual. > Perhaps this bug should go against pulseaudio... particularly if it was > updated? Sure, I would agree with that. But now I don't really know how Xfce attempts to start PA.
(In reply to Paul DeStefano from comment #2) > (In reply to Kevin Fenzi from comment #1) > > Also, Xfce should start pulseaudio on login if it's installed no matter what > > your session settings have. > > Okay, but that's very confusing. Why would that be? how does it do that if > it's not part of the session startup? Looking further I guess we don't do this anymore. We did around the time pulseaudio landed, and I thought we still did, but looks like we dropped that a while back... > > > Also, if it's not running and you run some audio application it should start it. > > That may be the case, I haven't really noticed. But, xkb-bell doesn't work > until it's already running and x11 module has been loaded. So, most of my > audio cues are broken unless it's started immediately. There's some pulseaudio bugs around x11 bell... > > So, some questions: > > > > 1. When did it last work as expected? > > As I said, it worked two weeks ago when I last rebooted, AFAIK. But, I > think it is likely this has been a problem for longer. Given your statement > about PA starting "on-access", I bet this has been happening since I > upgraded to F21, at least. Could be the kernel? Might try booting the previous one? > > 2. What changed since then? check /var/log/yum.log ? > > I updated with yum yesterday and pulseaudio pkgs were included in that. > pulseaudio is now 6.0-2. Wow, it looks like it was a full major revision > before this update, 5.0-25...in the middle of F21; that's unusual. Yeah. ;( > > Perhaps this bug should go against pulseaudio... particularly if it was > > updated? > > Sure, I would agree with that. But now I don't really know how Xfce > attempts to start PA. Sorry for the confusion... it does only use the session stuff now.
(In reply to Kevin Fenzi from comment #3) > There's some pulseaudio bugs around x11 bell... You're telling me? I'm all over those bug reports...10+ years. > > > So, some questions: > > > > > > 1. When did it last work as expected? > > > > As I said, it worked two weeks ago when I last rebooted, AFAIK. But, I > > think it is likely this has been a problem for longer. Given your statement > > about PA starting "on-access", I bet this has been happening since I > > upgraded to F21, at least. > > Could be the kernel? Might try booting the previous one? Interesting you suggest that; I'm not able to upgrade kernel. I tried and had to back out of 3.19.1. So, I'm at the same kernel I had when I thought this was working.
This may be a dup of bug #1206764 pulseaudio-6.0-2.fc21 changed how autostart works, to rely on autospawn behavior... except that doesn't work of users (for whatever reason) had disabled autospawn (see /etc/pulse/client.conf or ~/.pulse/client.conf and look for autospawn=no) If that is the case, either remove autospawn=no, or update to: https://admin.fedoraproject.org/updates/FEDORA-2015-5586/pulseaudio-6.0-2.fc21.1
(In reply to Rex Dieter from comment #5) > This may be a dup of bug #1206764 It may be a dup; I'm not sure. > pulseaudio-6.0-2.fc21 changed how autostart works, to rely on autospawn > behavior... except that doesn't work of users (for whatever reason) had > disabled autospawn (see /etc/pulse/client.conf or ~/.pulse/client.conf and > look for autospawn=no) /etc/pulse/client.conf hasn't any modifications. All lines look like comments; the only line with autospawn is '; autospawn = yes'. ~/.pulse/client.conf doesn't exist. > If that is the case, either remove autospawn=no, or update to: > https://admin.fedoraproject.org/updates/FEDORA-2015-5586/pulseaudio-6.0-2. > fc21.1 That's the version of PA I already have. AFAIK, Xfce session runs /usr/bin/start-pulseaudio-x11 and, at this time, that doesn't result in PA starting a (long-lived) daemon. If I start Rhythmbox, though, I get sound; I think that is what is intended. In that light, I guess my problem is really that xkbbell isn't a qualifying event that causes PA to auto-spawn. So, if /usr/bin/start-pulseaudio-x11 doesn't start PA, it's not running when xkbbell events are generated and sound is broken. On the other hand, I'm not sure what is the update in package 6.0-2 since /usr/bin/start-pulseaudio-x11 still doesn't start PA. I guess I could try killing PA and running it...yes, I get the same thing as posted in bug 1206764, comment 7: connection refused . So, to summarize: if start-pulseaudio-x11 is supposed to start PA, then it is broken and that's what I'm reporting. If it isn't supposed to start PA, then this is an unexpected change in Xfce desktop behavior. I'd prefer the desktop take control of that and that's what I'm reporting. Does that make sense?
If you examine /usr/bin/start-pulseaudio-x11, it basically just does : /usr/bin/pulseaudio --start /usr/bin/pactl load-module module-x11-publish /usr/bin/pactl load-module module-x11-cork-request /usr/bin/pactl load-module module-x11-xsmp "display=$DISPLAY session_manager=$SESSION_MANAGER" , so run each of these manually to see where the failure is for you.
And note: pulseaudio-6.0-2.fc21.1 != pulseaudio-6.0-2.fc21 see the .1 at the end? Are you sure you have pulseaudio-6.0-2.fc21.1 ?
Ah, okay, my mistake. I didn't have the updated pkg. I just upgraded to it and I have no doubt it will work.
(In reply to Rex Dieter from comment #7) > If you examine /usr/bin/start-pulseaudio-x11, it basically just does : > > /usr/bin/pulseaudio --start > /usr/bin/pactl load-module module-x11-publish > /usr/bin/pactl load-module module-x11-cork-request > /usr/bin/pactl load-module module-x11-xsmp "display=$DISPLAY > session_manager=$SESSION_MANAGER" > > , so run each of these manually to see where the failure is for you. I just use Fedora 22 with last update, and pulseaudio is: =================================== # rpm -qa | grep pulseaudio pulseaudio-libs-6.0-2.fc22.x86_64 pulseaudio-libs-glib2-6.0-2.fc22.x86_64 pulseaudio-module-x11-6.0-2.fc22.x86_64 pulseaudio-6.0-2.fc22.x86_64 alsa-plugins-pulseaudio-1.0.29-1.fc22.x86_64 kde-settings-pulseaudio-22-7.fc22.noarch pulseaudio-module-bluetooth-6.0-2.fc22.x86_64 pulseaudio-utils-6.0-2.fc22.x86_64 pulseaudio-module-gconf-6.0-2.fc22.x86_64 [root@encelade ~]# dnf update pulseaudio Last metadata expiration check performed 0:53:29 ago on Thu May 28 22:02:02 2015. Dependencies resolved. Nothing to do. Complete! [root@encelade ~]# ================== Here is the content of /usr/bin/start-pulseaudio-x11 in this package: ++++++++++++++++++++++++++++++++++++ set -e if [ x"$DISPLAY" != x ] ; then /usr/bin/pactl load-module module-x11-publish "display=$DISPLAY" > /dev/null /usr/bin/pactl load-module module-x11-cork-request "display=$DISPLAY" > /dev/null if [ x"$KDE_FULL_SESSION" = x"true" ]; then /usr/bin/pactl load-module module-device-manager "do_routing=1" > /dev/null fi if [ x"$SESSION_MANAGER" != x ] ; then /usr/bin/pactl load-module module-x11-xsmp "display=$DISPLAY session_manager=$SESSION_MANAGER" > /dev/null fi fi ++++++++++++++++++++++++++ SO, no command: /usr/bin/pulseaudio --start in this script the result is as described above: ++++++++++++++++++++++++ [root@encelade ~]# start-pulseaudio-x11 Connection failure: Connection refused pa_context_connect() failed: Connection refused ++++++++++++++++++++++++++++ BUT THIS IS ONLY IN ROOT ENVIRONMENT (experienced with MATE desktop) If I logon a MATE session with an ordinary user login, pulse audio is running automatically !!! Started by WHAT ???? Of cause if I do All, step by step, as Rex commented in comment 7, I get also pulseaudio working fine in Root environment
f21 reverted the change to take out pulseaudio --start to rely only on PA autospawn behavior. f22 did not see comment #6 to double check you don't have any custom autospawn = no
*** This bug has been marked as a duplicate of bug 1206764 ***