On Tue, 2014-09-16 at 14:27 +0200, David Henningsson wrote:
>
> On 2014-09-15 17:09, Felipe Sateler wrote:
> > On Mon, Sep 15, 2014 at 5:50 AM, Tanu Kaskinen
> > <tanu.kaskinen at linux.intel.com> wrote:
> >> On Wed, 2014-09-10 at 09:51 -0300, Felipe Sateler wrote:
> >>> I would think the daemon is per-session, not per-user, given that
> >>> (until systemd --user works) we cannot track user stuff across
> >>> sessions.
> >>
> >> We can, module-systemd-login exists for that purpose. It creates a
> >> client object for each session that the user has. As long as there are
> >> any client objects in PulseAudio, the server won't shut down
> >> automatically. When the last client exits, PulseAudio will exit after a
> >> delay (20 seconds by default).
> >
> > And what happens if I log in to X, switch to a VT, logout from X and
> > login again to X? As I understand the current status, the dbus session
> > is tied to the X server, so there should be a new session bus in thi
> > case. Does pulseaudio handle this situation correctly? (eg, will
> > bluetooth devices work after this?)
>
> This is all tricky stuff which we'll need to sort out in some smart way.
>
> First, as Tanu said, Bluetooth is tied to the system bus. This causes a
> problem of its own, given that if we have two different PA instances
> running simultaneously as two different users, who should have access to
> the bluetooth device(s)? Does anybody know if this handled correctly? [1]
My /etc/dbus-1/system.d/bluetooth.conf has this:
<policy at_console="true">
<allow send_destination="org.bluez"/>
</policy>
I'm not sure, but I think this means that only the user who has an
active session on a seat can access the D-Bus API of BlueZ. If a user is
actively using a BT device when switching users, however, I don't think
PulseAudio will automatically release the device.
On a multi-seat system with multiple simultaneous active users this is
probably more broken. Something might happen on this front at some
point, since we will have to deal with this in Tizen somehow, as we try
to support multi-seat configurations including Bluetooth.
> Second, for ALSA and the mute issue, I think we need to notify PA
> somehow that the system is going down, either for suspend, hibernate or
> poweroff. And that needs to complete before ALSA mutes things. This has
> nothing to do with X sessions.
Does ALSA do the muting also when suspending or hibernating? I haven't
noticed such behaviour, but then again, I haven't noticed the poweroff
muting either...
> Third, the lifetime of the PulseAudio instance should follow the
> lifetime dictated by systemd-logind (or other login manager). This is
> because we have our native socket in XDG_RUNTIME_DIR, i e
> /run/user/<uid>/pulse. PulseAudio should quit before this directory is
> removed. Also, this also dictates that we can have at most one PA
> instance per user, otherwise they will end up overwriting each other's
> socket files.
So what do you propose? Should we not apply the Debian patch, nor tweak
the auto-exit delay? I'm fine with either: tweak the auto-exit delay (if
someone writes a patch) or not do anything (in which case Debian will
have to keep patching PulseAudio until the Real Fix somehow
materializes).
(Some nitpicking: we can have more than one PA instance per user, if the
extra instances are started with a different XDG_RUNTIME_DIR.)
--
Tanu
