[pulseaudio-discuss] Issues with pulseaudio and gdm

[Colin Guthrie]

Hi,

Sorry for the crazy late reply.

'Twas brillig, and Neil Bird at 09/06/12 00:39 did gyre and gimble:
>   I've posted this in the Fedora list and googled around without
> success, so this is my next stop.
> 
>   Long story short, I have Fedora 16, upgraded from F14 (and earlier),
> but pulseaudio is not running (or dying) for the gdm+gnome-shell
> session, although it *really* wants it.  All normal users are fine.

So pulseaudio is not running for gdm? It could be that it tries to
startup but fails. I do remember seeing a while back a problem that gdm
wasn't able to access bluetooth via dbus for some reason and this
actually stopped PA starting as gdm. Might be unrelated however.

If you turn up PA logging, it should tell you the necessary info.

>   The side effect is that, some while after logging in, or possibly as I
> switch users, I get an entry in /var/log/messages every few seconds
> about a pulseaudio authorisation error.  I believe I have tracked these
> down to gdm's gnome-shell & gnome-settings-daemon trying to talk to *my*
> login's pulseaudio (as it's the first login and is sitting on the
> default port?).

Interesting. The connection code may indeed try localhost as a fallback
but it's odd that it's not connecting to it's own PA daemon. Has it's
own PA daemon exited by this stage?

>   Unlike my freshly-installed laptop, and the VM I created to test it, I
> don't seem to have one run from start-up, although it might be stopping
> before or as I log in.

I'm not sure, but certainly with recent gdm's and PA's I do happily get
PA running. There is some talk of not running it due to the startup
delay it introduces (what with all the probing) especially as the there
is no login-ready sound by default these days.

>   I've tried running pulseaudio manually as gdm, but it seems to just
> exit by its own volition.  I'm running strace again on a daemon I've run
> up now.  I tried earlier today from my laptop but couldn't see anything
> but a seeming deliberate clean exit.  It doesn't automatically respawn
> like I'd expect.

There were several issues in session handling in PA where gdm had a kind
of deadlock with the logind module in PA. Those were issues really in
systemd which I fixed in recent versions, but I'm not sure they would be
to blame on a F16 setup, so likely not related.

>   I've even copied the X11-start-pulseaudio .desktop file into gdm's
> autostart directory, and this seems to (usually) work from power up (I
> actually get an audio icon in gdm's gnome-shell's panel that makes a
> sound) but it goes when gdm's pulseaudio does, which I *think* is when I
> first log in.

Actually I'm pretty sure GDM shouldn't run this script. It will inject
variables into the root window that might confuse your logged in users
after it hands the X11 root window over to them.

>   Has anyone got any ideas as to where I should start looking at this?
>  What's *supposed* to start pulseaudio?  I replaced pulseaudio in my
> test VM with a script that would do a ps and then run the real
> pulseaudio, and that indicates that it's gnome-settings-daemon that's
> spawning the pa exe, but I can't find anything explicit in the gsd source.

Pulseaudio autospawns itself when it's needed so it's in the libpulse
code. By trying to connect to a PA daemon that is not running, g-s-d's
use of the libpulse code will trigger the autospawn.

>   I'm running the rtkit daemon, I have gdm in the pulse-rt and
> pulse-access groups (along with all local users), and I *don't* have
> anyone in the audio group (which I think causes lock problems).

OK, so the pulse-rt group is not needed with rtkit ad the pulse-access
group is only relevant for system-wide daemons, so again it's not
relevant here.

>   I am having random rhythmbox lock-up issues which may or may not be
> related, and I *used* to have a problem with gdm locking pulseaudio out
> (such the my user account could often not access sound), so I tried a
> couple of fixes at the time to stop gdm trying to make sounds.  I
> *think* I've undone these, but may have something stray hanging about. I
> can't see anything in files, gconf or dconf, though.

If you've previously added any users to the audio group that will
generally mess things up, but it shouldn't result in actual connection
issues and authentication failures.


Useful debug info would be:

ps aux | grep pulseaudio
xprop -root | grep PULSE_ | grep -v PULSE_COOKIE


I guess the most interesting bit is why launching via gsd+autospawn
didn't work.

Certainly I don't have issues with that here with newer gsd+PA, so it's
perhaps a problem that has just "gone away" now :s

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/