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.
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.
*** Bug 5462 has been marked as a duplicate of this bug. ***
https://bugzilla.redhat.com/show_bug.cgi?id=510177
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.
First script committed in r30510. Just launches the system pulseaudio daemon (if present). Does not handle disconnects though.
Building and shipping our own pulseaudio in r30513.
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
Automatic connection handling added in r30514 and r30515.
Switched over to the global esound socket in r30517.
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.
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.
(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.
I'm also getting a crash on logout on my Fedora 22 test machine.
(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)
(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.
(In reply to comment #15) > I'm also getting a crash on logout on my Fedora 22 test machine. Fixed in r30540.
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.
(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.
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).
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.)
Volume control is also not behaving as expected. It seems like flat-volumes isn't active for some reason. Need to investigate.
(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.
(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.
(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.
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.
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.
Urgh. Stumbled upon bug 5110 as part of this. Need to fix that as well I suppose.
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.
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.
(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
Verified code, looks good. However I couldn't find any way to reproduce the origin problem. eg. everything works flawless.
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.
This seems to be something in Gnome. It doesn't happen with KDE. The problem is present both on RHEL 7 and Fedora 22.
(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.
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.
(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.
