I get no sound in my desktop when using the following (a bit usual) way to start the desktop: from a virtual terminal, say vt2, run: (setsid startx -- vt7 &). That is, startx in a virtual terminal other than the current one. The "setsid" is not relevant here, without it, (startx -- vt7 &) don't work, either. But, if I play something in the desktop and then SWITCH BACK to vt2, the sound comes. If I log into another virtual terminal, for example, vt1, the sound comes, too. Just as long as I switch back to desktop on vt7, the sound stops. I guess this is because pulseaudio fails to recognise the active session: if I run `pacmd list-sinks` in the desktop(vt7), it shows that the status of the active sink is "SUSPENDED" and the suspend cause is "SESSION" while running the same command in vt2 shows the status is "RUNNING". Also, `loginctl user-status` shows that, all processes of my desktop(vt7) and vt2 belong to the same session (in systemd's notion). And if I start X by: (setsid startx -- vt2 &) that is, in the same virtual terminal, then all problems are gone, pulseaudio works perfectly. I'm using arch linux, mate desktop(1.8.0), pulseaudio(5.0), all packages are from arch's official repository.
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.
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.