No sound on Debian Buster.

[bobhwasatch]

Just upgraded to Debian Buster. Xrdp sound had previously worked fine with the xrdp-pulseaudio-installer package in Stretch. However that package is no longer available so I followed the instructions here to build manually.

I was able to successfully build the xrdp source and sink libraries. They get loaded and I can connect with the volume control. I did have to modify /etc/pulse/default.pa to get them to load, as /etc/xrdp/pulse/default.pa seems to be getting ignored.

When I start playback of a YouTube video, I get no sound and the following message repeats in syslog as long as audio is playing:

Jul 13 12:42:19 robin pulseaudio[1424]: E: [xrdp-sink] module-xrdp-sink.c: 1 block_usec 30000 Jul 13 12:42:19 robin pulseaudio[1424]: E: [xrdp-sink] module-xrdp-sink.c: 1 block_usec 30000

The volume control (pavucontrol) does show audio coming from Chrome, but the sound never gets to my rdp client.

ETA: It also seems that it takes a long time to connect to the pulseaudio server. The pavucontrol client displays a "trying to connect" message for about 30 seconds before showing the main screen.

[bobhwasatch]

First, I replaced /etc/pulse/default.pa with /etc/xrdp/pulse/default.pa. That got the modules to load.

Then, running pulseaudio with "log-level=debug" revealed that the xrdp modules have the wrong path for the chanserv sockets. I got it to work with this workaround:

ln -s /tmp/.xrdp /var/run/xrdp/sockdir cd /var/run/xrdp/sockdir ln -s xrdp_chanserv_audio_out_socket_10 xrdp_chanserv_audio_out_socket_0 ln -s xrdp_chanserv_audio_out_socket_10 xrdp_chanserv_audio_out_socket_0

[bobhwasatch]

Ok, I'm an idiot. The real problem was that the XRDP_SOCKET_PATH and PULSE_SCRIPT environment variables in /etc/xrdp/sesman.ini were not getting carried through to my desktop environment where pulseaudio was being started.

I had modified the startwm.sh script so that it just called rather than exec-ing the desktop session. I guess that was a problem because the variables were not exported? In any case reverting back to the default startwm.sh provided by Debian along with adding the XRDP_SOCKET_PATH to sesman.ini made it work.

In /etc/xrdp/sesman.ini:

[SessionVariables] XRDP_SOCKET_PATH=/var/run/xrdp/sockdir PULSE_SCRIPT=/etc/xrdp/pulse/default.pa

The /etc/xrdp/startwm.sh is the Debian Buster default one.

It is also important that /etc/xrdp/pulse/default.pa has the correct path to where the xrdp pulseaudio modules are installed.

Sorry for the confusion.

[vermeeren]

I am having sound on buster, but with 5-10 sec delay. See #24

@bobhwasatch any specific settings you have? Could you also say which RDP client you use?

[bobhwasatch]

For a client I mostly use Xtralogic RDP for Chrome OS but sometimes Apache Guacamole as well. I don't think I have any special settings on the client side. My server settings are in a previous post. sound is working for both. I sometimes have minor sync issues with video but nothing as bad as your report.

My Buster install is a VM running under Proxmox, not a physical machine. I also have a Win 10 VM and sound works ok on that as well with the same clients. Both VMs have 4 cores and 4 GB allocated. The server is lightly loaded most of the time.

On Mon, Sep 30, 2019 at 6:06 AM Melvin Vermeeren [email protected] wrote:

I am having sound on buster, but with 5-10 sec delay. See #24 https://github.com/neutrinolabs/pulseaudio-module-xrdp/issues/24

@bobhwasatch https://github.com/bobhwasatch any specific settings you have? Could you also say which RDP client you use?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/neutrinolabs/pulseaudio-module-xrdp/issues/31?email_source=notifications&email_token=ABAD3XX3UHY7CARJOXDUZF3QMH2WZA5CNFSM4IDBKSXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD75SF2Q#issuecomment-536552170, or mute the thread https://github.com/notifications/unsubscribe-auth/ABAD3XSPHEXR4BRFAXCGWDLQMH2WZANCNFSM4IDBKSXA .

-- Sent via my private email server!

[bobhwasatch]

Hmm...I haven't used sound for a while and when I tried it today I see the same 5-second delay before the sound starts playing. I don't know when it started but I don't remember it being there initially.

ETA: The reason I didn't notice this may be because I was using Apache Guacamole to access the VM. The problem seems much less severe on Guacamole. Perhaps it keeps the sound channel always open?

[acharintsev]

Hmm...I haven't used sound for a while and when I tried it today I see the same 5-second delay before the sound starts playing. I don't know when it started but I don't remember it being there initially.

ETA: The reason I didn't notice this may be because I was using Apache Guacamole to access the VM. The problem seems much less severe on Guacamole. Perhaps it keeps the sound channel always open?

Temporarily solved the problem with a pause in the sound. Rolled back to Pulseaudio version 9.0.

[jsorg71]

Hm, so there seems to be a problem with v12. I can take a look on buster. We might be doing latency wrong and the new PA server is more strict.

[jsorg71]

I have create #38 for possible fix.

[metalefty]

This might be related to neutrinolabs/xrdp#1265. FreeBSD had PulseAudio 12 (and now has 13).

[dioptre]

Hey @bobhwasatch can you share your configs? default.pa? I tried everything here and everything I could find and none of the prior suggestions helped.

I got Assertion 'PA_SINK_IS_LINKED failed and

pa_sink_process_rewind(). Aborting

Using mostly stuff I found:

https://c-nergy.be/blog/?p=12469
apt install m4 libtool
sudo apt-get install libsndfile-dev
sudo apt-get install libcap-dev
cd /tmp
sudo apt source pulseaudio 
cd /tmp/pulseaudio*
sudo ./configure

https://github.com/neutrinolabs/pulseaudio-module-xrdp/wiki/README
apt install build-essential dpkg-dev libpulse-dev
apt install pulseaudio
apt build-dep pulseaudio
apt source pulseaudio
cd pulseaudio-11.1
./configure


sudo apt install ffmpeg
sudo apt-get install libav-tools
https://misstg.aiwayan.com/bjgn9k/debian-buster-xrdp.html
https://forums.docker.com/t/cant-make-audio-device-to-work-on-aws-solved/71852/3

[bobhwasatch]

I actually just did a new install on Debian 10 (buster). Everything worked as described in the README except I had to add PKG_CONFIG_DIR to the xrdp-pulse configure command. I added these lines to the existing /etc/xrdp/pulse/default.pa:

.ifexists /usr/local/lib/pulse-12.2/modules/module-xrdp-source.so
load-module /usr/local/lib/pulse-12.2/modules/module-xrdp-source.so
.endif

.ifexists /usr/local/lib/pulse-12.2/modules/module-xrdp-sink.so
load-module /usr/local/lib/pulse-12.2/modules/module-xrdp-sink.so
.endif

I'm using Debian 10 (buster) and it has pulse-12.2 rather than 11. What distribution are you using? Perhaps the install path is different than /usr/local/lib. I don't see your bootstrap or configure commands for xrdp-pulseaudio, did you get any errors from them? Based on that assertion failure I would guess that something didn't get linked or installed. That stuff from docker.com seems like he's kind of doing it manually and doesn't seem relevant at all.

[dioptre]

Ah interesting, I downloaded the sources to 13 with the instructions I found (sudo apt source pulseaudio). I'll try again with 12.2 soon. Thanks!

[rolnas]

The problem is that pulseaudio is started from user systemd session process and it doesn't inherit environment from xrdp/startwm.sh. I checked it with "ps axeww". I just stopped user pulseaudio with "systemctl --user stop pulseaudio.socket" and started pulseaudio manually - sound works in Debian 10 buster. I compiled module-xrdp-sink.so from git with pulseaudio sources from buster (not backports).

[rolnas]

PULSE_SCRIPT and XRDP_SOCKET_PATH are system wide, but XRDP_PULSE_* are session specific. Tried to put "systemctl --user stop pulseaudio; pulseaudio --start" in startwm.sh - doesn't work.

[rolnas]

Finally I found a working workaround. I put "systemctl --user import-environment" just before exec Xsession lines and it worked.

[O2Graphics]

Thanks @rolnas for your solution, unfortunately it wasn't enough to make it work on a Debian based distribution. I also had to add: systemctl --user restart pulseaudio right after your line.

It's sad we have two deal with two of the three* worst pieces of software ever made: pulseaudio and systemd.

*The third is, of course, avahi.

[rolnas]

After many years with SysV background initially I was already in trouble with systemd. With time I'm finding good and bad sides of this solution. pulseaudio is a solution to solve multiple application access to audio device problem. But if you care about latency, ALSA layer is only solution, but only for one application.

Thanks @rolnas for your solution, unfortunately it wasn't enough to make it work on a Debian based distribution. I also had to add: systemctl --user restart pulseaudio right after your line.

It's sad we have two deal with two of the three* worst pieces of software ever made: pulseaudio and systemd.

*The third is, of course, avahi.