On Ubuntu 14.04 LTS client old laptop
(X2Go audio forwarding over an SSH tunnel to localhost)
By default, the module binds to all interfaces (0.0.0.0 — meaning it could accept connections from anywhere on the network).
Adding listen=127.0.0.1 forces it to bind only to the loopback interface (localhost). This is a common security recommendation when you only need local/tunneled connections (like X2Go does), to prevent accidental exposure to the real network.
In practice, for localhost-only use, it's optional because the default port (4713) isn't usually exposed externally anyway, but it's "safer".
sudo nano /etc/pulse/default.pa
### Network access
load-module module-native-protocol-tcp listen=127.0.0.1 auth-ip-acl=127.0.0.1 auth-anonymous=1
ABOVE LINE IS SOLUTION IN MY CASE
pulseaudio --kill
pulseaudio --start
pactl info
You should see Server String... and so on... if access denied, smth is wrong.
No need to add client user to audio group!
The issue you're running into is that your manual configuration forces the PipeWire/PulseAudio server on the Kubuntu 24.04 machine to listen on **127.0.0.1:4713** and then manually points applications to it via `PULSE_SERVER=tcp:127.0.0.1`. This makes sound play locally on the server (and duplicate across sessions because multiple user sessions share the same local output).
X2Go's built-in audio forwarding works differently and more securely:
- It **does not** require (or want) the server's PulseAudio to listen on a TCP port.
- Instead, X2Go starts a PulseAudio server **on the client side** (your Ubuntu 14.04 laptop).
- It then SSH-tunnels a connection back from the server session to a local forwarded port on the server (e.g., localhost:30000 → client:4713).
- X2Go automatically sets `PULSE_CLIENTCONFIG` and `PULSE_COOKIE` in the server session to point to this tunneled port.
This way, sound from applications in the X2Go session is redirected over the encrypted SSH tunnel to the client's speakers — no local playback on the server, no duplication across sessions.
### How to fix it and get sound on the client
1. **Remove your manual TCP configuration on the server**
(Do this as the user, e.g., `sudo -u ubuntu14client -i` or in their session)
```
rm ~/.config/pipewire/pipewire-pulse.conf.d/60-tcp.conf
systemctl --user restart pipewire pipewire-pulse
```
This disables the TCP listener on 127.0.0.1.
2. **Remove the manual PULSE_SERVER from the user's profile**
Edit `~/.profile` (or wherever you added it) and remove/unset these lines:
```
unset PULSE_CLIENTCONFIG
export PULSE_SERVER=tcp:127.0.0.1:4713
```
Or simply comment them out. Log out/in or source the file to apply.
3. **On the X2Go client (Ubuntu 14.04 laptop)**
- Make sure PulseAudio is installed and working locally:
```
sudo apt update
sudo apt install pulseaudio pavucontrol
```
- Ensure the client's PulseAudio allows network/tunneled connections (it usually does by default, but you can force it if needed):
```
pactl load-module module-native-protocol-tcp auth-anonymous=1
```
(This is temporary; add it to `/etc/pulse/default.pa` if you want it persistent.)
4. **In your X2Go client session settings**
- Go to the session tab → "Shared folders" / general settings.
- Set **Sound system** to **PulseAudio**.
- Important: Check the box **"Use SSH port forwarding for audio"** (or similar wording — it's the tunneled option). This is usually the default and recommended.
5. **Start a new X2Go session**
- Terminate any running sessions first.
- Connect with the above settings.
Sound from applications in the X2Go session should now play on your Ubuntu 14.04 laptop's speakers only — no local server playback, no duplication.
If it still doesn't work:
- Check in the server session: `echo $PULSE_CLIENTCONFIG` — it should point to a file with `default-server = localhost:3xxxx` (a forwarded port).
- On the client, run `pactl info` to confirm PulseAudio is running.
- Test client audio locally first (e.g., play a sound file).
This is the standard, secure way X2Go handles PulseAudio forwarding and works reliably on modern Ubuntu/Kubuntu (including PipeWire-based ones like 24.04). Your manual TCP setup bypassed X2Go's mechanism, which caused the local playback.
The "pactl info" showing "access denied" (or more precisely, often "Connection failure: Access denied") on your **Ubuntu 14.04 laptop (the X2Go client)** is a common issue with older PulseAudio versions when trying to accept **tunneled connections** (which is exactly what X2Go does for secure audio forwarding).
By default, older PulseAudio (like in Ubuntu 14.04) requires cookie-based authentication even for localhost connections, and the forwarded tunnel can trigger an "invalid authentication data" denial.
### Quick Fix (Recommended for X2Go)
On the **client** (Ubuntu 14.04 laptop), make PulseAudio allow anonymous authenticated connections from localhost (safe because the tunnel is over encrypted SSH and only from 127.0.0.1):
1. Edit the system-wide PulseAudio config (as root):
```
sudo nano /etc/pulse/default.pa
```
2. Add this line at the end:
```
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1 auth-anonymous=1
```
(This loads the TCP protocol module and allows anonymous access **only** from localhost — perfect for the SSH tunnel.)
3. Restart PulseAudio:
```
pulseaudio --kill
pulseaudio --start
```
Or simply log out and back in (or reboot if needed).
4. Now test locally:
```
pactl info
```
It should show server info without "access denied".
### Alternative (Temporary, No Config Change)
If you don't want to edit files permanently, run this **before** starting the X2Go session (or add it to your ~/.bashrc):
```
pactl load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1 auth-anonymous=1
```
This loads the module just for your current session.
### Why Adding to 'audio' Group Doesn't Help
The "audio" group is for direct hardware access (ALSA devices like /dev/snd/*).
PulseAudio client connections (like pactl or tunneled ones) use UNIX socket or TCP authentication — **not** the audio group. That's why adding the user had no effect.
### Next Steps for X2Go Audio
- Keep your previous cleanup on the **server** (no manual TCP listener, no manual PULSE_SERVER in .profile).
- Ensure X2Go client session settings: Sound system = **PulseAudio**, and use SSH port forwarding for audio (usually default).
- Start a **new** X2Go session.
- Play a sound on the server side (e.g., in a terminal: `aplay /usr/share/sounds/alsa/Front_Center.wav` or open a video).
- It should now come out on your laptop speakers only.
If you still get issues:
- On the client, run `pactl info` again after connecting — it should work.
- Check client-side logs: `tail ~/.x2goclient/logs/*.log | grep pulse` for clues.
THIS REDIRECTS ALL SOUND TO SERVER
YOU WON'T HEAR ANYTHING ON CLIENT
NOT EXPECTED SOLUTION
On Kubuntu 24.04 server
sudo -u ubuntu14client -i
mkdir -p ~/.config/pipewire/pipewire-pulse.conf.d/
cd ~/.config/pipewire/pipewire-pulse.conf.d/
nano ~/.config/pipewire/pipewire-pulse.conf.d/60-tcp.conf
pulse.cmd = [
{ cmd = "load-module" args = "module-native-protocol-tcp listen=127.0.0.1" }
]
On Ubuntu 14 client
Close X2GOclient session and relogin
To fix the "Dummy Output" issue in X2Go and ensure YouTube sound plays on the server speakers, follow this persistent, "set-it-and-forget-it" method.
Kubuntu 24.04 uses PipeWire, which reads configuration from your home directory with higher priority than system files. By placing these files on the server, you ensure that whenever your user logs in (remotely or locally), the server's audio engine is ready to accept your browser's audio stream.
1. On the Server: Setup the TCP "Receiver"
You are configuring the server to listen for audio on its own local network interface (127.0.0.1).
Location: ~/.config/pipewire/pipewire-pulse.conf.d/60-tcp.conf
Why: This tells the server's PipeWire process: "Keep a door open at port 4713 so applications can send me sound data directly".
2. On the Server: Setup the Session Environment
You are also editing the .profile on the server for your specific user account.
Location: ~/.profile
Why: When you log in via X2Go, the server reads this file.
unset PULSE_CLIENTCONFIG stops X2Go from trying to hijack the audio [previous context].
export PULSE_SERVER=tcp:127.0.0.1:4713 tells every app you launch (like Firefox or Chrome) to send its sound to that "door" you opened in Step 1.
Summary Checklist for the Server
Create Config: mkdir -p ~/.config/pipewire/pipewire-pulse.conf.d/
Add TCP Rule: Create 60-tcp.conf with the pulse.cmd block.
Update Profile: Add the unset and export lines to ~/.profile.
Permissions: Run sudo usermod -a -G audio $USER so your user has the right to talk to the physical speakers.
Restart: Run systemctl --user restart pipewire-pulse (or just reboot the server).
Once this is done, you don't need to do anything on your client laptop except connect via X2Go with "Enable sound support" unchecked. The sound will stay on the server and play through its speakers automatically.
Because you are using PipeWire on the server with the TCP module and no .asoundrc locking the hardware, the system is doing exactly what it was designed to do:
Session 1 (Local User): Playing music directly to the PipeWire daemon.
Session 2 (Your X2Go Session): Sending audio via TCP to that same PipeWire daemon.
The Result: PipeWire acts as a mixer, combining both streams and outputting them to the physical server speakers simultaneously. No "Device Busy" errors!
Why it's working now:
The TCP Bridge: By using PULSE_SERVER=tcp:127.0.0.1:4713, you bypassed the isolated "Dummy Output" that X2Go usually creates.
The PipeWire Mixer: Unlike old ALSA (which could only handle one app at a time without complex dmix setups), PipeWire handles the mixing of multiple users and streams automatically.
Permissions: Adding yourself to the audio group gave your remote session the "keys" to the hardware.
How to manage this "Double Audio":
If you ever find it annoying that both sessions are playing at once, you can control them individually without leaving your X2Go window:
Open pavucontrol (PulseAudio Volume Control) in your X2Go session.
Go to the Playback tab.
You will see your Browser (YouTube) listed there. You can slide the volume down or mute it without affecting the music the local user is playing.
If you want to see what the other user is playing, you usually can't for security reasons—but you can always see your own "Stream" and control its volume relative to the server's master volume.
Also keeping the option to play on the server, you need to use a "Combined Sink" or a graphical patchbay. This allows you to route audio to your remote session and the server hardware simultaneously.
1. The Quickest Fix: Graphical Patchbay
Instead of complex command-line arguments, use a visual tool to "draw a line" between your browser and your local sound card.
On the server, install qpwgraph:
sudo apt install qpwgraph
Launch it within your X2Go session.
You will see boxes for your applications (like Firefox) and outputs (the server's speakers and the X2Go virtual output).
Drag a line from the output of Firefox to both your server's hardware and the X2Go sink. Now the sound plays in both places.
2. The Persistent Fix: Combined Sink
You can create a virtual "Combined Sink" that automatically duplicates every sound to both the server and your remote client.
On the server, run this command to create a virtual device that "combines" all outputs:
pactl load-module module-combine-sink sink_name=combined-output
Open pavucontrol in your X2Go session.
Go to the Playback tab.
While a video is playing, change the output device for the browser to "Simultaneous output on...".
Now the sound will be sent to the server speakers and your remote X2Go client (your laptop) at the same time.
3. Re-enabling X2Go Sound Support
For your laptop to receive the audio, you must revert the previous step where we unchecked sound support:
Disconnect your X2Go session.
In X2Go Client settings, go to Media and Check "Enable sound support" again.
Select PulseAudio as the protocol.
Reconnect. And it WON'T WORK!
No comments:
Post a Comment