Bug 76672

The SESSION suspend cause is used when pulseaudio doesn't have permission to use the sound card. The sound card permissions are controlled outside pulseaudio (maybe in logind, but I don't really know the details). It sounds like this is not a pulseaudio issue, unless you actually can access the sound card inside the session where pulseaudio is not working.

(In reply to comment #1)
> The SESSION suspend cause is used when pulseaudio doesn't have permission to
> use the sound card. The sound card permissions are controlled outside
> pulseaudio (maybe in logind, but I don't really know the details). It sounds
> like this is not a pulseaudio issue, unless you actually can access the
> sound card inside the session where pulseaudio is not working.

I've read somewhere that using the normal configuration of pulseaudio (no user is in the audio group, which is the case of my system), pulseaudio will automatically change the acl of the sound hardware according to the current active user. I've checked that on my system:

when in desktop(vt7), `getfacl /dev/snd/controlC0` gives no acl permission to the current user while running the same command in vt2 shows that correct acl permission is given to the current user.

So yes, this may probably be the real cause of the issue. Is it sure that the device acl is not controlled by pulseaudio? Can you please help pinpoint which program is in charge of the device acls?

(In reply to comment #2)
> when in desktop(vt7), `getfacl /dev/snd/controlC0` gives no acl permission
> to the current user while running the same command in vt2 shows that correct
> acl permission is given to the current user.
> 
> So yes, this may probably be the real cause of the issue. Is it sure that
> the device acl is not controlled by pulseaudio?

Yes, it's sure.

> Can you please help pinpoint
> which program is in charge of the device acls?

Sorry, as I said, I don't know the details.

(In reply to comment #2)
> I've read somewhere that using the normal configuration of pulseaudio (no
> user is in the audio group, which is the case of my system), pulseaudio will
> automatically change the acl of the sound hardware according to the current
> active user. I've checked that on my system:
> 
> when in desktop(vt7), `getfacl /dev/snd/controlC0` gives no acl permission
> to the current user while running the same command in vt2 shows that correct
> acl permission is given to the current user.
> 
> So yes, this may probably be the real cause of the issue. Is it sure that
> the device acl is not controlled by pulseaudio? Can you please help pinpoint
> which program is in charge of the device acls?

It should be either in systemd-logind or consolekit, depending on what your distro uses.

(In reply to comment #4)
> 
> It should be either in systemd-logind or consolekit, depending on what your
> distro uses.

So it must be systemd-logind, arch has removed consolekit for a while.

Thanks. I will try to ask help in the systemd community.

This will tell, do:

loginctl list-sessions


and from that output, pick yours to get more detail, using
loginctl show-session


for example, on my box:

$ loginctl list-sessions
   SESSION        UID USER             SEAT            
         3       1000 rdieter1         seat0

$ loginctl show-session 3
Id=3
Timestamp=Tue 2014-04-08 05:43:25 CDT
TimestampMonotonic=120200722
VTNr=2
Display=:0
Remote=no
Service=kdm
Scope=session-3.scope
Leader=1326
Audit=3
Type=x11
Class=user
Active=yes
State=active
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
Name=rdieter1

See the "Active=yes" in there?  I believe that is what is required.

-- 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/233.