On Tue, Sep 16, 2014 at 11:32 AM, David Henningsson <david.henningsson at canonical.com> wrote: > > > 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? I was never able to reproduce. Unfortunately, the diagnosis is quite old, so I don't know if something changed that might have fixed the problem. The original report is here[1]. This patch comes originally from another bug report[2], which mentions another two bugs[3][4]. As you can see, all of the reports are fairly old, so I'm not sure if anything has changed in this regard. The alsa shutdown script was a debian thing, apparently[5]. However alsa-utils upstream now includes systemd service files[6]. The two do not seem to be functionally equivalent, so perhaps the debian specific sysvinit script was problematic. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556971 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594001 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593746 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593952 [5] http://sources.debian.net/src/alsa-utils/1.0.28-1/debian/init/ [6] http://sources.debian.net/src/alsa-utils/1.0.28-1/alsactl/ -- Saludos, Felipe Sateler
