www.cendio.com
Bug 4194 - start a server side pulseaudio daemon for each session
: start a server side pulseaudio daemon for each session
Status: CLOSED FIXED
: ThinLinc
Sound
: 3.2.0
: PC Unknown
: P2 Normal
: 4.5.0
Assigned To:
:
:
: 5110 5589
: 2432 4016
  Show dependency treegraph
 
Reported: 2012-02-06 15:01 by
Modified: 2015-09-25 13:59 (History)


Attachments


Note

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


Description From cendio 2012-02-06 15:01:52
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 From cendio 2013-10-17 14:43:50 -------
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 From cendio 2015-03-06 13:56:58 -------
*** Bug 5462 has been marked as a duplicate of this bug. ***
------- Comment #5 From cendio 2015-03-06 14:28:24 -------
https://bugzilla.redhat.com/show_bug.cgi?id=510177
------- Comment #6 From cendio 2015-04-13 09:18:36 -------
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 From cendio 2015-06-26 14:20:33 -------
First script committed in r30510. Just launches the system pulseaudio daemon
(if present). Does not handle disconnects though.
------- Comment #8 From cendio 2015-06-26 14:28:09 -------
Building and shipping our own pulseaudio in r30513.
------- Comment #9 From cendio 2015-06-26 16:37:30 -------
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 From cendio 2015-06-26 16:39:15 -------
Automatic connection handling added in r30514 and r30515.
------- Comment #11 From cendio 2015-06-26 16:58:37 -------
Switched over to the global esound socket in r30517.
------- Comment #12 From cendio 2015-06-26 17:04:07 -------
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 From cendio 2015-06-30 13:53:16 -------
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 From cendio 2015-06-30 14:40:07 -------
(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 From cendio 2015-06-30 15:22:48 -------
I'm also getting a crash on logout on my Fedora 22 test machine.
------- Comment #16 From cendio 2015-06-30 16:06:02 -------
(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 From cendio 2015-06-30 17:09:12 -------
(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 From cendio 2015-07-01 10:16:01 -------
(In reply to comment #15)
> I'm also getting a crash on logout on my Fedora 22 test machine.

Fixed in r30540.
------- Comment #19 From cendio 2015-07-01 14:02:42 -------
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 From cendio 2015-07-01 14:54:20 -------
(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 From cendio 2015-07-02 15:31:31 -------
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 From cendio 2015-07-13 13:26:37 -------
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 From cendio 2015-07-13 13:27:18 -------
Volume control is also not behaving as expected. It seems like flat-volumes
isn't active for some reason. Need to investigate.
------- Comment #24 From cendio 2015-07-13 14:36:46 -------
(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 From cendio 2015-07-13 14:37:23 -------
(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 From cendio 2015-07-13 15:23:54 -------
(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 From cendio 2015-07-16 16:46:23 -------
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 From cendio 2015-07-17 14:07:01 -------
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 From cendio 2015-08-11 15:25:22 -------
Urgh. Stumbled upon bug 5110 as part of this. Need to fix that as well I
suppose.
------- Comment #30 From cendio 2015-08-24 13:53:00 -------
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 From cendio 2015-09-01 14:12:52 -------
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 From cendio 2015-09-02 11:06:00 -------
(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 From cendio 2015-09-08 13:35:49 -------
Verified code, looks good. However I couldn't find any way to reproduce the
origin problem. eg. everything works flawless.
------- Comment #39 From cendio 2015-09-14 15:10:09 -------
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 From cendio 2015-09-15 14:21:06 -------
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 From cendio 2015-09-15 15:49: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.

We've also seen occasional lockups in the pulseaudio server. Will try to see if
I can reproduce the problem.
------- Comment #43 From cendio 2015-09-16 09:39:54 -------
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 From cendio 2015-09-16 11:00:05 -------
(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.