XRDP Guide: Part 2 — Enabling System Audio on Ubuntu and Debian

By Calabastro

In the previous article of this series, we established a remote desktop session between your Windows workstation and an Ubuntu or Debian Linux server. We successfully routed the display, keyboard, and mouse over RDP.

However, upon logging in for the first time, you likely noticed something missing: silence.

Unlike a standard desktop installation where audio starts automatically when you log into the graphical interface, a headless Linux server does not have a default “Login Screen” to trigger sound services. Consequently, even if your server has sound hardware installed (or is an emulated sound card in a VM), XRDP will pass the video stream perfectly while dropping all audio packets because the background service isn’t running yet.

This guide details how to configure PulseAudio specifically for headless Linux servers so you can route system sound from your remote session back to your Windows machine.

Prerequisites

XRDP Installed: You should have completed Part 1 of this guide and be able to remote into the desktop.
Hardware: Your server must have access to sound hardware. On a dedicated physical machine, this requires a sound card. On a Virtual Machine (VMware/VirtualBox/KVM), you must ensure the virtual machine is configured with an audio controller (usually “Intel HD Audio” or “AC97”).

Step 1: Install PulseAudio and Debug Tools

Ubuntu and Debian use PulseAudio as their default sound server. We need to install the daemon itself, along with a utility called pavucontrol (PulseAudio Volume Control). While you won’t use it every day, it is essential for debugging why audio might be muted or routed incorrectly later.

sudo apt update
sudo apt install pulseaudio pavucontrol libpulse-dev -y

libpulse-dev: This package is crucial if your XRDP installation wasn’t compiled with sound support built-in; it ensures the necessary libraries are present for binding to the audio system.

Step 2: Enable Sound in XRDP Configuration

XRDP, by default, may attempt to ignore sound requests to save resources on the server. We need to explicitly tell it to bridge audio to PulseAudio.

Open the sesman configuration file:

sudo nano /etc/xrdp/sesman.ini

Locate the section labeled [Xorg].

You will see a list of parameters such as param=Xvnc or arg=-config xrdp/xorg.conf.

Find the line that looks like this:

Sound=none

Change it to pulse.

Sound=pulse

Save and exit the file (Ctrl+O, Enter, Ctrl+X).

Step 3: Start PulseAudio on Headless Servers (Crucial)

This is the specific step required for headless servers. On a PC with a monitor attached, the audio starts when you click “Login” at the greeter screen. On a headless server, there is no login screen, so we must create a trigger that starts the PulseAudio daemon automatically as soon as a user connects via XRDP.

We will do this by adding a startup script to the profile directory.

Create a new file for system-wide profile execution:

sudo nano /etc/profile.d/start_pulse.sh

Paste the following content into the file. This script checks if PulseAudio is running; if not, it starts it in system mode to bypass user session permission issues

#!/bin/bash
# Check if PulseAudio is already running
if ! ps -A | grep -v grep | grep pulseaudio > /dev/null
then
    echo "Starting PulseAudio for headless XRDP..."
    # Start as a daemon with high priority to prevent audio glitches
    /usr/bin/pulseaudio --system -D --daemonize=true 
fi

Make the script executable:

sudo chmod +x /etc/profile.d/start_pulse.sh

Permission Setup: Because we are running PulseAudio in “system mode” (allowing it to talk to hardware directly), we must grant your users permission to control the audio device. Create the system group:

sudo addgroup --system pulse-access

Add your primary user (and root, if necessary) to this group: # Replace 'username' with your actual login name

sudo usermod -aG pulse-access username

Step 4: Restart XRDP Services

Now that the software is installed and the scripts are in place, restart the XRDP services to apply the configuration changes.

sudo systemctl restart xrdp
sudo systemctl restart xrdp-sesman

Step 5: Configure Windows Remote Desktop Client

The server-side configuration allows audio to be captured, but your Windows computer needs to know where to send it. You may need to re-connect the session for these changes to take effect fully, or simply log out and log back in on the Linux side.

Open Remote Desktop Connection (mstsc.exe) on your Windows machine.
Click “Show Options” (or “Options” in newer versions).
Navigate to the Local Resources tab.
Under the Remote audio section, click “Settings…”.
Select “Play on this computer”.
From the dropdown menu, ensure your local speakers or headphones are selected.
Click OK, then Connect.

Troubleshooting Audio Issues

If you connect and still hear silence, follow these checks:

1. Check the Virtual Output
Once logged into your Linux desktop, open a terminal (Ctrl+Alt+T) and type:

pavucontrol

Go to the Output Devices tab.
If you see a “Fallback Device” but all sliders are grayed out or at 0%, right-click and enable it.
Ensure it hasn’t been set to “Dummy Output.”

2. The First Connection Glitch
Sometimes, the very first connection after configuring start_pulse.sh may result in static or silence because the PulseAudio daemon takes a few seconds to initialize but XRDP has already grabbed the stream. Log out of the Linux session and log back in; the second attempt usually works perfectly.

3. Microphone Input (Optional)
If you need to use your Windows microphone on the Linux server:

Go back to Local Resources > Remote Audio.
Click Settings, then check “Record from this computer”.
Note that your Linux audio levels in pavucontrol under the Input Devices tab must be unmuted.

Conclusion

With these steps completed, your headless Linux server is now a fully functional remote workstation. You have video over RDP, and you have system audio routed back to your local machine. This creates a truly seamless experience for running multimedia applications, listening to music, or attending conference calls directly through your Linux management server.

Triii Technologies LLC