Bug 4194 - start a server side pulseaudio daemon for each session
Summary: start a server side pulseaudio daemon for each session
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Sound (show other bugs)
Version: 3.2.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.5.0
Assignee: Pierre Ossman
URL:
Keywords: derfian_tester, hean01_tester, relnotes
: 5462 (view as bug list)
Depends on: 5110 5589
Blocks: 2432 4016
  Show dependency treegraph
 
Reported: 2012-02-06 15:01 CET by Pierre Ossman
Modified: 2015-09-25 13:59 CEST (History)
4 users (show)

See Also:
Acceptance Criteria:


Attachments

Description Pierre Ossman cendio 2012-02-06 15:01:52 CET
We might want to start a pulseaudio deamon for each session, mimicking a "normal" local session. This has a few advantages:

- There is always something for local application to talk to, avoiding noise in xinit.log and general odd behaviour.

- Streams are combined on the server, reducing bandwidth

- Automatic reconnection is probably easier to handle.

- Compression is probably easier to handle.
Comment 1 Peter Åstrand cendio 2013-10-17 14:43:50 CEST
We had a problem report on Issue14593 where Metacity took 100% CPU with a reconnected session. We got a strace, showing that it constantly tries to connect to the PulseAudio server. This is done through the libcanberra.so.0, which is written by Lennart Poettering. 

If we had a server side daemon, we could better handle such broken applications.
Comment 3 Samuel Mannehed cendio 2015-03-06 13:56:58 CET
*** Bug 5462 has been marked as a duplicate of this bug. ***
Comment 5 Samuel Mannehed cendio 2015-03-06 14:28:24 CET
https://bugzilla.redhat.com/show_bug.cgi?id=510177
Comment 6 Pierre Ossman cendio 2015-04-13 09:18:36 CEST
kde also behaves horribly. It spams this rapidly to xinit.log when pulseaudio is missing:

> kded(15148)/kmix context_state_callback: Connection to PulseAudio daemon closed. Attempting reconnection. 
> kmix(15341) context_state_callback: Connection to PulseAudio daemon closed. Attempting reconnection.
Comment 7 Pierre Ossman cendio 2015-06-26 14:20:33 CEST
First script committed in r30510. Just launches the system pulseaudio daemon (if present). Does not handle disconnects though.
Comment 8 Pierre Ossman cendio 2015-06-26 14:28:09 CEST
Building and shipping our own pulseaudio in r30513.
Comment 9 Pierre Ossman cendio 2015-06-26 16:37:30 CEST
Urgh. esound doesn't support specifying a unix socket in $ESPEAKER. You can only have a single unix socket per user, called /tmp/.esd-<uid>.

Trying to dynamically assing a port number is going to be very messy. So realistically we have two options:

 - Let esound stuff bypass the session server and talk directly to the client.

 - Only a single session per user will have working esound
Comment 10 Pierre Ossman cendio 2015-06-26 16:39:15 CEST
Automatic connection handling added in r30514 and r30515.
Comment 11 Pierre Ossman cendio 2015-06-26 16:58:37 CEST
Switched over to the global esound socket in r30517.
Comment 12 Pierre Ossman cendio 2015-06-26 17:04:07 CEST
Session PulseAudio server enabled by default in r30518.

That should hopefully be all. Now we just need to test and see that we don't have any regressions.
Comment 13 Pierre Ossman cendio 2015-06-30 13:53:16 CEST
Tested Gnome 3 and found some issues:

 - A lot of stuff in Gnome 3 is dbus activated and because dbus is started early it will not have the proper environment. Hence those applications bypass the session PulseAudio server.

 - We hacked the PulseAudio tunnel module to say "ThinLinc client". We should remove that and do something more generic.
Comment 14 Pierre Ossman cendio 2015-06-30 14:40:07 CEST
(In reply to comment #13)
>  - A lot of stuff in Gnome 3 is dbus activated and because dbus is started
> early it will not have the proper environment. Hence those applications bypass
> the session PulseAudio server.
> 

This one is a bit annoying. The quick-and-dirty solution of simply starting pulseaudio before dbus is probably not a good idea as dbus tends to be required by most modern software, including pulseaudio.

I think I'll have to play around with separating modifying the environment and actually starting the session server.
Comment 15 Pierre Ossman cendio 2015-06-30 15:22:48 CEST
I'm also getting a crash on logout on my Fedora 22 test machine.
Comment 16 Pierre Ossman cendio 2015-06-30 16:06:02 CEST
(In reply to comment #14)
> (In reply to comment #13)
> >  - A lot of stuff in Gnome 3 is dbus activated and because dbus is started
> > early it will not have the proper environment. Hence those applications bypass
> > the session PulseAudio server.
> > 
> 
> This one is a bit annoying. The quick-and-dirty solution of simply starting
> pulseaudio before dbus is probably not a good idea as dbus tends to be required
> by most modern software, including pulseaudio.
> 
> I think I'll have to play around with separating modifying the environment and
> actually starting the session server.

Fixed in r30536.

Tester should check:

 - dbus applications. Easily done using Gnome 3 and opening "Sound" from the launcher. Note that you cannot launch Gnome control center from the top bar. Verify that "gnome-control-center" has the dbus server as its PPID.

 - check that audio is sent directly to the client if the session server dies (bonus feature)
Comment 17 Pierre Ossman cendio 2015-06-30 17:09:12 CEST
(In reply to comment #13)
>  - We hacked the PulseAudio tunnel module to say "ThinLinc client". We should
> remove that and do something more generic.

Fixed in r30537 and r30538.

Also reported upstream:

https://bugs.freedesktop.org/show_bug.cgi?id=91159

Tester should verify that the client still identifies itself with the proper name and icon, in both "auto" and "pulseaudio" mode.

Should also test that the session server uses a proper name by connecting directly to the client's pulseaudio server and listing clients.
Comment 18 Pierre Ossman cendio 2015-07-01 10:16:01 CEST
(In reply to comment #15)
> I'm also getting a crash on logout on my Fedora 22 test machine.

Fixed in r30540.
Comment 19 Pierre Ossman cendio 2015-07-01 14:02:42 CEST
Doesn't work on Windows for some odd reason. Something is off with the latency feedback so video players will just pause the video. Works just fine if you bypass the session server though, or use a Linux client.
Comment 20 Pierre Ossman cendio 2015-07-01 14:54:20 CEST
(In reply to comment #19)
> Doesn't work on Windows for some odd reason. Something is off with the latency
> feedback so video players will just pause the video. Works just fine if you
> bypass the session server though, or use a Linux client.

Damn Heisenbug. Can't reproduce it now. I'm still seeing something off with the latencies on Windows does as reported by pactl. Need to check if something is broken, or if it's just confusing output by pactl.
Comment 21 Pierre Ossman cendio 2015-07-02 15:31:31 CEST
The latency handling in module-tunnel is already known to be very poor. So it's better to solve this by doing bug 5589 and switching to the new tunnel modules (which I've tested and they work fine).
Comment 22 Pierre Ossman cendio 2015-07-13 13:26:37 CEST
pacmd doesn't work. It seems it needs the cli module, and the pid file. There seems to be an environment variable that controls the runtime dir, so that we can make sure we get a pid per session.

(It also respects XDG_RUNTIME_DIR, but I don't think we should fiddle with that as the standard explicitly states that it should be shared between multiple sessions by the same user.)
Comment 23 Pierre Ossman cendio 2015-07-13 13:27:18 CEST
Volume control is also not behaving as expected. It seems like flat-volumes isn't active for some reason. Need to investigate.
Comment 24 Pierre Ossman cendio 2015-07-13 14:36:46 CEST
(In reply to comment #22)
> pacmd doesn't work. It seems it needs the cli module, and the pid file. There
> seems to be an environment variable that controls the runtime dir, so that we
> can make sure we get a pid per session.
> 
> (It also respects XDG_RUNTIME_DIR, but I don't think we should fiddle with that
> as the standard explicitly states that it should be shared between multiple
> sessions by the same user.)

Fixed in r30598.
Comment 25 Pierre Ossman cendio 2015-07-13 14:37:23 CEST
(In reply to comment #21)
> The latency handling in module-tunnel is already known to be very poor. So it's
> better to solve this by doing bug 5589 and switching to the new tunnel modules
> (which I've tested and they work fine).

Bug 5589 is now closed and things behave more sanely. Still more work and testing to be done though.
Comment 26 Pierre Ossman cendio 2015-07-13 15:23:54 CEST
(In reply to comment #23)
> Volume control is also not behaving as expected. It seems like flat-volumes
> isn't active for some reason. Need to investigate.

Apparently you need to enable dB scale for flat volumes. That should be fine for us though since it is all software volumes where the ratio is well known.

Fixed in r30600.
Comment 27 Pierre Ossman cendio 2015-07-16 16:46:23 CEST
Bug 5589 is now fixed and everything is working much better.

This however means that the tester should test things using both a new and old client, to make sure we haven't caused a dependency on an updated PulseAudio in the client.
Comment 28 Pierre Ossman cendio 2015-07-17 14:07:01 CEST
Seems to work rather nicely now on all platforms. The extra server adds a bit extra latency, but it's still within tolerable levels. See bug 5590 for further work in this area.
Comment 29 Pierre Ossman cendio 2015-08-11 15:25:22 CEST
Urgh. Stumbled upon bug 5110 as part of this. Need to fix that as well I suppose.
Comment 30 Henrik Andersson cendio 2015-08-24 13:53:00 CEST
Following tests were performed using client 4.4.0post build 8668 on Linux and 4.4.0 on Windows. Everything worked nicely except that client side pulseaudio server does not change the output volume (visually) missing hard link ?.

  - Killing pulseaduio server running in session will make sound to fallback to old playback directly to client pulse audio server.
  - STOP / CONT signals on server side pulseaudio daemon
  - pacmd within session
  - flat volume propagation to client
  - ESound (tested using esdplay)
  - Started gnome-control-center with dbus as parent id and verified that everything looked good.
Comment 31 Pierre Ossman cendio 2015-09-01 14:12:52 CEST
Getting crashes on logout again on my Fedora 22 with gnome shell:

E: [pulseaudio] core.c: Assertion 'pa_hashmap_isempty(c->modules_pending_unload)' failed at pulsecore/core.c:206, function core_free(). Aborting.
Comment 34 Pierre Ossman cendio 2015-09-02 11:06:00 CEST
(In reply to comment #31)
> Getting crashes on logout again on my Fedora 22 with gnome shell:
> 
> E: [pulseaudio] core.c: Assertion
> 'pa_hashmap_isempty(c->modules_pending_unload)' failed at pulsecore/core.c:206,
> function core_free(). Aborting.

Probably this upstream bug:

https://bugs.freedesktop.org/show_bug.cgi?id=90108
Comment 38 Henrik Andersson cendio 2015-09-08 13:35:49 CEST
Verified code, looks good. However I couldn't find any way to reproduce the origin problem. eg. everything works flawless.
Comment 39 Karl Mikaelsson cendio 2015-09-14 15:10:09 CEST
Reconnecting to a session playing audio will set output volume to 100%.

This is NOT what you expect when you have headphones on.

I usually adjust the output volume by the keyboard buttons. New applications launch with the current output volume selected.

I started a ThinLinc client and started playing some music (at about 30-40% volume), disconnected and reconnected to the session. When reconnecting, the output volume was suddenly set to 100%, making the ThinLinc client MUCH louder than earlier.
Comment 40 Pierre Ossman cendio 2015-09-15 14:21:06 CEST
This seems to be something in Gnome. It doesn't happen with KDE. The problem is present both on RHEL 7 and Fedora 22.
Comment 42 Pierre Ossman cendio 2015-09-15 15:49:42 CEST
(In reply to comment #40)
> This seems to be something in Gnome. It doesn't happen with KDE. The problem is
> present both on RHEL 7 and Fedora 22.

This was a race. I have no idea why it was only seen in Gnome.

We've also seen occasional lockups in the pulseaudio server. Will try to see if I can reproduce the problem.
Comment 43 Pierre Ossman cendio 2015-09-16 09:39:54 CEST
The hangs seem to be in the client as I cannot play anything by bypassing the session server either. Still, it's very difficult to reproduce so we'll have to wait until more information surfaces.
Comment 44 Karl Mikaelsson cendio 2015-09-16 11:00:05 CEST
(In reply to comment #42)
> (In reply to comment #40)
> > This seems to be something in Gnome. It doesn't happen with KDE. The problem is
> > present both on RHEL 7 and Fedora 22.
> 
> This was a race. I have no idea why it was only seen in Gnome.

Works great now.

Note You need to log in before you can comment on or make changes to this bug.