Audio redirect not automatically starting

[orthorhombic]

Auto starting of the xrdp sink doesn't seem to be working for all users, and I suspect this is due to a combination of restrictive umask issues and missing system-wide configuration. Though it does not auto-start at initiation of an xrdp session, I can successfully get audio redirects working after running pulseaudio --start or pulseaudio -D in a terminal.

My initial suspicion is that the file permissions on /usr/libexec/pulseaudio-module-xrdp/load_pa_modules.sh and /etc/xdg/autostart/pulseaudio-xrdp.desktop are too restrictive due to the default umask and need to be explicitly placed with 755 on the folders. Otherwise they seemed to be installed fine.

Initial troubleshooting with sudo ls -la /usr/libexec/ output:

-rwxr-xr-x  1 root root  121504 Feb 26 06:11 polkitd
-rwxr-xr-x  1 root root   67968 Mar  5 12:17 power-profiles-daemon
drwxr-x---  2 root root    4096 May 12 23:41 pulseaudio-module-xrdp
-rwxr-xr-x  1 root root   14736 Feb 16 09:20 qmi-proxy
-rwxr-xr-x  1 root root  109024 Feb 17 13:39 rhythmbox-metadata

In an effort to address this, I manually changed the permissions on these:

sudo chmod -R 755 /usr/libexec/pulseaudio-module-xrdp
sudo chmod 755 /etc/xdg/autostart/pulseaudio-xrdp.desktop

I think this might be configurable in https://github.com/neutrinolabs/pulseaudio-module-xrdp/blob/devel/instfiles/Makefile.am? I'm not familiar with makefile.am files, so don't initially know how to set this there.

After manually changing the permissions of these two files, I found that sound over XRDP was automatically starting and working, but only for the user I originally ran the wrapped script from. When logging in with another user, I found I needed to run pulseaudio -D to start up a pulseaudio server. This immediately enabled the redirect to work. I'm not familiar enough with pulseaudio to know what the cause of this may be (yet).

The user configuration files populated (~/.config/pulse/, listed below) seem to be what is missing. Though I don't know what the function is, copying these files from one user to another (and restarting) fixes the issue. Maybe if we could instead replicate this configuration in the system config at /etc/pulse/ it may fix things for all users? At least in an initial skim of this codebase, I'm not sure where this might be configured.

For reference, mainuser is the user the scripts from this repo were run as.

mainuser@server:~$ sudo ls -al /home/otheruser/.config/pulse
total 12
drwx------  2 otheruser users 4096 May 14 21:51 .
drwx------ 11 otheruser users 4096 May 12 23:26 ..
lrwxrwxrwx  1 otheruser users   23 May 14 21:51 bf564f865dce40fba054c86133c1c28c-runtime -> /tmp/pulse-PKdhtXMmr18n
-rw-------  1 otheruser users  256 May 12 23:24 cookie
mainuser@server:~$ sudo ls -al /home/mainuser/.config/pulse
total 36
drwx------  2 mainuser mainuser 4096 May 10 01:19 .
drwx------ 11 mainuser mainuser 4096 May 14 22:11 ..
-rw-------  1 mainuser mainuser  696 May 10 01:19 bf564f865dce40fba054c86133c1c28c-card-database.tdb
-rw-------  1 mainuser mainuser    1 May 12 23:26 bf564f865dce40fba054c86133c1c28c-default-sink
-rw-------  1 mainuser mainuser    1 May 12 23:26 bf564f865dce40fba054c86133c1c28c-default-source
-rw-------  1 mainuser mainuser 8192 May 10 01:19 bf564f865dce40fba054c86133c1c28c-device-volumes.tdb
-rw-------  1 mainuser mainuser  696 May 10 01:19 bf564f865dce40fba054c86133c1c28c-stream-volumes.tdb
-rw-------  1 mainuser mainuser  256 May 10 01:19 cookie

I'm happy to put in a PR if I find a successful implementation. Suggestions are welcome!

[matt335672]

Hi @orthorhombic

Regarding your two points:- 1) We use autotools to perform all the heavy lifting for us. I've had a look at this, and there is a lack of agreement on what should happen with a restrictive umask on install. See https://bug-automake.gnu.narkive.com/PmSlfjdn/bug-12130-sudo-make-install-applies-umask-to-new-directories.

The simplest solution in this case might be to document the behaviour. With a restrictive umask, you can use this command instead:-

   sudo make install MKDIR_P="mkdir -p -m 0755" INSTALL_SCRIPT="/usr/bin/install -m 0755"

2) If I'm reading you right, you want to connect to the desktop with one user and run a sound application as another user. Is that right?

[orthorhombic]

Regarding 2 - Sorry for my lack of clarity. I'm hoping to install things with one user, and have the xrdp sound redirect available to all users on the system.

So following my example, if mainuser installs the module, I hope that otheruser will have the redirect work when logging in. In both cases, I would connect from windows with the built in RDP client, and then once presented with the XRDP splash screen, I would enter user credentials for either of the two users. Does that make more sense?

[matt335672]

It sounds like you're looking for a system-wide pulseaudio daemon to me:-

• https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/SystemWide/

This isn't a normal set-up. Normally if mainuser and otheruser are logged in to separate xrdp sessions, you'd expect them to have separated sound systems.

What would you expect to happen if both mainuser and otheruser are logged in over xrdp? Would you expect them to get the same sounds? I don't think this is a use-case we've ever considered. Might be interesting to try, but changes may be needed.

[orthorhombic]

Again, sorry for my lack of clarity and knowledge of pulseaudio. I'm aiming for that "normal" case where if mainuser and otheruser are logged into separate xrdp sessions, they get separated sound systems.

I think the issue for me is the automatic startup of the daemon isn't working for otheruser unless I copy over the config files. I haven't even thought to test what happens if both users are logged in at the same time.

Thanks again for your quick responses!

[matt335672]

I'm hardly a pulseaudio expert myself!

Both users should end up with completely separate pulseaudio daemons, and separate systemd --user processes. If that's not working there's possibly some coupling between the two that needs to be removed.

I've just tried this on my system with testuser and xtestuser, both running separate xrdp sessions. It seems to be working as I described:-

$ ps -ef | grep 'testus.*pulseaudio'
xtestus+    1569    1561  2 09:09 ?        00:00:22 /usr/bin/pulseaudio --daemonize=no --log-target=journal
xtestus+    1846    1796  0 09:10 ?        00:00:00 /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-2.0 /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libpulseaudio-plugin.so 8 12582921 pulseaudio PulseAudio Plugin Adjust the audio volume of the PulseAudio sound system
testuser    2155    2149  0 09:12 ?        00:00:00 /usr/bin/pulseaudio --daemonize=no --log-target=journal
mjb         2943    1266  0 09:24 pts/0    00:00:00 grep --color=auto testus.*pulseaudio

If I run this command to see what paplay is successfully opening:-

strace paplay /usr/share/sounds/gnome/default/alerts/glass.ogg 2>&1 | grep 'open.*= [1-9]'

I get the following:-

<snipped>
openat(AT_FDCWD, "/usr/share/sounds/gnome/default/alerts/glass.ogg", O_RDONLY|O_NOCTTY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", O_RDONLY) = 3
openat(AT_FDCWD, "/etc/pulse/client.conf", O_RDONLY|O_CLOEXEC) = 7
openat(AT_FDCWD, "/etc/pulse/client.conf.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 8
openat(AT_FDCWD, "/usr/share/locale-langpack/en_GB/LC_MESSAGES/libc.mo", O_RDONLY) = 8
openat(AT_FDCWD, "/dev/shm/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 7
openat(AT_FDCWD, "/dev/urandom", O_RDONLY|O_NOCTTY|O_CLOEXEC) = 7
openat(AT_FDCWD, "/run/user/1002/pulse", O_RDONLY|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC) = 8
openat(AT_FDCWD, "/home/xtestuser/.config/pulse/cookie", O_RDONLY|O_NOCTTY|O_CLOEXEC) = 9
openat(AT_FDCWD, "/etc/machine-id", O_RDONLY|O_CLOEXEC) = 9

/run/user/1002/pulse is the directory containing the default socket for user xtestuser (UID 1002). The cookie needed by the server is in /home/xtestuser/.config/pulse/cookie.

Is that useful?