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