On 2014-09-16 15:09, Tanu Kaskinen wrote:
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
<[email protected]> 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.
Ok, sounds like a plan.
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...
Felipe, could you elaborate on this? I think I've seen such a mute
script, but I'm not sure if it was upstream or debian specific, perhaps
it's even removed these days?
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).
At this point, I don't have any concrete proposal. In Ubuntu, I wrote an
inotify that kills PA whenever XDG_RUNTIME_DIR is removed [1]. But you
did not like this patch.
Removing the 20-second delay sounds like the right thing to do, but I
wonder if it will cause startup problems? E g, if PA autospawns, and
there are no systemd modules or anything else keeping it alive (e g
because the user does not run systemd), and it's waiting for a client to
connect?
(Some nitpicking: we can have more than one PA instance per user, if the
extra instances are started with a different XDG_RUNTIME_DIR.)
Okay, is this something we actively support, and that we won't cause
troubles anywhere else? (I suspect loading the esd support module won't
work...)
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
[1]
http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-April/017015.html
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
