Okay so I did a bit of research, and found a method of forwarding audio from your remote RDP Linux desktops.
The methods work for RDP connections on your local LAN, and also for connections to remote systems via ssh tunnels.
Here's how…
2012-04-19 Article Updated
Changelog:
- Added a section for how to get audio on Windows Clients from the linux RDP target
Prerequisites
- The client system needs PulseAudio – client and server – installed. These days it's installed by default if you've installed a full desktop Debian/Ubuntu distribution. Update : Also works for Windows, which also needs PulseAudio – see new section for Windows below!
- The target system needs the PulseAudio client libraries installed. No need for the PulseAudio server, although this is probably already installed if you've installed the Gnome Desktop and/or Unity.
A) Local LAN RDP connections…
Here's the basic setup; a client system and the target system running Xrdp/X11rdp.
The client system's IP address is 192.168.1.9.
The target systems's IP address is 192.168.1.254.
The system you're going to listen to audio on is the rdp client, but it's the PulseAudio server. The RDP target system will send all audio data to the PulseAudio server running on your client machine.
1) On the Client System
Ensure the PulseAudio TCP native protocol module is set up on your client system.
Open up a terminal window on your local system, and type the following;
pacmd list-modules | grep module-native-protocol-tcp
If the response is blank, then this module is not loaded. To load it, type the following;
pactl load-module module-native-protocol-tcp auth-ip-acl="<ip address or network range>"
Where <ip address or network range>
can be a single ip address – for example 192.168.1.254
– or a network range such as 192.168.1.0/24
. The former will limit access to the PulseAudio server running on your client system. The latter will grant PulseAudio server access to all systems on that network. You can also specify a list of IP addresses separated with a semicolon. For example; "192.168.1.101;192.168.1.102;192.168.1.254"
, which would limit access to the systems on the LAN with those addresses.
Once you've loaded this module successfully, you'll see a number returned – this is the module ID number. You can unload the module if you wish to try different configurations, by typing pactl unload-module <ID number>
.
2) On the Target RDP System
In the user's ~/.xsession
file, add this line BEFORE any lines which start your gnome or unity-2D session…
export PULSE_SERVER=<ip address of your client machine>
So for example, my client machine's address is 192.168.1.9. The line would read export PULSE_SERVER=192.168.1.9
Save the .xsession
file.
Here's what my .xsession file looks like;
export PULSE_SERVER=192.168.1.9:4713
gnome-session --session=gnome-fallback
3) Connect via RDP
From your client machine, use your favorite RDP client to connect to the target RDP system as usual.
Any audio output from programs running in the RDP session should now automatically be heard on your client system.
Also, if you right-click on the audio icon on your desktop (I'm using the gnome-classic desktop for my RDP sessions), then click on Sound Preferences, you can control the audio output of the RDP session, just as if the sound hardware were on the RDP target machine :)
Here's a screenshot of a gnome-classic session running on rdesktop. I brought up the Sound Preferences and clicked the Hardware tab. Thanks to Pulseaudio's magic, the sound card on my client machine appears – as if it's installed on the RDP server.
Magic, I say. Magic!
I'm running RhythmBox in that session as I type this, and the audio's coming through just fine ;)
And that's it for audio on RDP for the local LAN. Next up is doing the same on a truly remote system…
B) Audio on RDP on remote connections…
The method is similar to the above for LAN connections, except that we're going to be doing this through ssh tunnels.
Prerequisites
- The client system needs PulseAudio – client and server – installed. These days it's installed by default if you've installed a full desktop Debian/Ubuntu distribution.
- The target system needs the PulseAudio client libraries installed. No need for the PulseAudio server, although this is probably already installed if you've installed the Gnome Desktop and/or Unity.
1) On the Client System
We'll need an SSH tunnel between the client machine, and your target machine.
If you don't know how that's done, I suggest you read the article I wrote recently on how to do exactly that ;)
For the purposes of this article, I'm going to form an ssh tunnel between my client, and a machine on my LAN at 192.168.1.254 – the principle is exactly the same, and I've tried this on a remote VPS system too.
I've tried this procedure on a remote machine over the internet (a VPS), and the sound was choppy when playing sound from Google Chrome (a YouTube video. I don't know if that's a result of a bursty connection or what, so, your results may vary – your results for this might be brilliant, or just as bad as the result I achieved, so, be warned.
When I ran Rhythmbox though and played a radio station, the sound came through just fine.
Also, when I ran Gnome Terminal and caused an "audible bell" by pressing backspace when no characters were left to delete, the sound was choppy.
So, basically mixed results for remote audio over the internet – Your Mileage May Vary, etc etc
As with the LAN scenario, ensure the PulseAudio TCP native protocol module is set up on your client system.
Open up a terminal window on your local system, and type the following;
pacmd list-modules | grep module-native-protocol-tcp
If the response is blank, then this module is not loaded. To load it, type the following;
pactl load-module module-native-protocol-tcp auth-ip-acl="127.0.0.1"
Since we're going to use an SSH tunnel for this, all we need is access allowed on the locahost interface. You can, if you're going to be accessing RDP systems on the local LAN as well as remote, say "127.0.0.1;<ip address or range>" as we did above, though.
2) On the Target RDP System
In the user's ~/.xsession
file, add this line BEFORE the line(s) which start your gnome or unity-2D session…
export PULSE_SERVER=<localhost:4713>
.xsession
file.export PULSE_SERVER=localhost:4713
gnome-session --session=gnome-fallback
3) Form the SSH tunnel connection between your client system and the SSH target system.
ssh -c arcfour -R localhost:4713:localhost:4713 -L3390:localhost:3389 <ip address of ssh target system>
ssh -c arcfour -R localhost:4713:localhost:4713 -L3390:localhost:3389 192.168.1.254
ssh -c arcfour -R localhost:4713:<ip address of RDP server>:4713 -L localhost:3390:<ip address of RDP server>:3389 <ip address of ssh target system>
4) Connect to your RDP server via the ssh tunnel
rdesktop -a16 -g 1820x900 localhost:3390
for my connection as an example.And now for Windows clients :D
That's right, you read it right – you can get audio working from your Linux RDP server to your Windows RDP client machine, Like A Boss. Here's how…
A) Local LAN RDP connections…
Same basic scenario as above.
I have a Linux target RDP server on my LAN at 192.168.1.249
I have a Windows client on the LAN at 192.168.1.10
1) On the Windows client system…
C:\PulseAudio
.C:\PulseAudio\etc\pulse\default.pa
#load-module module-null-sink
load-module module-native-protocol-tcp listen=0.0.0.0 auth-anonymous=1
C:\PulseAudio\etc\pulse\daemon.conf
exit-idle-time = -1
cd c:\PulseAudio\bin
pulseaudio.exe -p "C:\PulseAudio\lib\pulse-1.1\modules" -nF "C:\PulseAudio\etc\pulse\default.pa"
B) Audio on RDP on remote connections…
We'll need an SSH tunnel between the client machine, and your target machine.
If you don't know how that's done, I suggest you read the article I wrote recently on how to do exactly that ;)
For the purposes of this article, I'm going to form an ssh tunnel between my client, and a machine on my LAN at 192.168.1.254 – the principle is exactly the same as if the RDP server was at a remote location over the internet, and I've tried this on a remote VPS system too.
1) Configure puTTY On the Client System…
Configure a Session Name and enter the Host IP address.
Local
radio-button is selected as shown.Source port
is 3391
(Windows uses 3390 already).Destination
is localhost:3389
.Add
.Remote
radio-button is selected, as shown.Source
should be 4713
Destination
should be localhost:4713
Add
.export PULSE_SERVER=localhost:4713
Connect to the remote system via puTTY, using the session details you saved from above.
The two tunnels should now be active. Let's see…
4) Connect to an RDP session…
This time round, we're connecting to localhost:3391 – that's the RDP tunnel formed by the puTTY connection.
Good, the RDP tunnel is working, so let's log in…
And bingo! The PulseAudio tunnel is working!
Play something and it should work – it did for me :)
Lastly, here's the SSH tunnel to my VPS. The above setup worled on that too, and audio was playing fine – you may get some distortion on a truly remote system if you're running the PulseAudio control panel like I am on the remote machine.
And that's it! :)
Please let me know how you got on with this!
Get audio with your xrdp/x11rdp connections, LAN or Remote! Updated! Windows Clients!,
first of all thank you for your detailed descriptions… GREAT.
Do you think there is a way to route audio regularely to mstsc?
Thank you – willi
Wilhelm, greetings!
There probably is a way to do this, I'm working on it – it will probably be by using PulseAudio on the Windows client machine.
I'll update the article if and when I get this working.
Stay tuned ;)
Regards.
From http://xrdp-devel.766250.n3.nabble.com/Xrdp-devel-audio-redirection-td4015803.html it looks like you'd just have to put –enable-simplesound in the file. Any thoughts?
Willhelm,
I updated the article with all you'll need to hear audio on your Windows client – let me know how you get on :)
Regards
Thank you Kevin for your help but that is not what I really require.
It is no problem to use pulseaudio for rdp-audio on a dedicated client – thanks to your work on it…
My Problem is:
assume there is a blackbox, say on a boat, serving wlan to any clients.
In the charter bizz every skipper nowadays likes to use his own notebook or tablet. Usually they have a notebook with some WindOS in it… and mstsc.exe very well unknown to them on their own box.
How easy it could be to provide them a blackbox.rdp on their desktop having their "marine radio" natively.
On the other hand, a boat is usually small enough to provide audio directly from the "blackbox" i.e. with bluetooth headsets.
But providing it really professional….
I think the trick is to clone ms-ts or to patch x11rdp to send audio on the same port ms-ts does..
Anyways.. thank you and do not throw much time in… I can, have to, live with a less professional solution…
brgds
Heh :P
Quite possibly, the freerdp project might do what you want – I haven't spent a lot fo time looking into what FreeRDP can do yet – and I don't think I'll have the time for the rest of this year – I am in the middle of a whole load of personal stuff right now which is eating all my time.
Anyway, hope you find the solution you're lookming for – if you do, let me know ;)
Regards
Dear Kevin,
I have been a quite old fan of you for the work that you have done till now especially for Remote Desktop system with Linux. I have been following all your posts and have tested almost all of them. They were all great to follow.
This time I am writing to you without testing this "Audio Forwarding Over RDP" stuff. Which I would like you to forgive me for.
Further I have a question about how Audio forwarding will work when there are more than 1 clients attached to an XRDP server. I mean do they all get their separate audio or it is possible for only one client and 1 server.
Following You
Chaitanya
Chaitanya , hi and thanks :)
If you have more than 1 client connecting to the target RDP server , then I would think that each client should get its own audio stream;
Alice is using client machine 1
Bob is using client machine 2
Both are connecting to the target RDP server under their own login names (alice, and bob)
If they're on the same LAN, then they should still be okay, as each has "diverted" their Pulseaudio stream from their login session to their client machine. If they're connecting through their own SSH tunnels, then the same is true.
Finally, if you try this out for yourself, please let me know the results! ;)
Regards
When I run the following command:
pulseaudio.exe -p "C:\PulseAudio\lib\pulse-1.1\modules" -nF "C:\PulseAudio\etc\pulse\default.pa"
I get:
W: [(null)] pulsecore/core-util.c: Secure directory creation not supported on Wi
n32.
W: [(null)] pulsecore/core-util.c: Secure directory creation not supported on Wi
n32.
W: [(null)] pulsecore/core-util.c: Secure directory creation not supported on Wi
n32.
W: [(null)] pulsecore/core.c: failed to allocate shared memory pool. Falling bac
k to a normal memory pool.
W: [(null)] pulsecore/core-util.c: Secure directory creation not supported on Wi
n32.
W: [(null)] pulsecore/core-util.c: Secure directory creation not supported on Wi
n32.
W: [(null)] pulsecore/core-util.c: Secure directory creation not supported on Wi
n32.
W: [(null)] modules/module-waveout.c: Sample spec not supported by WaveIn, falli
ng back to default sample rate.
E: [(null)] modules/module-waveout.c: Failed to open WaveIn.
E: [(null)] modules/module-waveout.c: Error: A device ID has been used that is o
ut of range for your system.
E: [(null)] pulsecore/module.c: Failed to load module "module-waveout" (argument
: "sink_name=output source_name=input"): initialization failed.
E: [(null)] daemon/main.c: Failed to load directory.
E: [(null)] daemon/main.c: Module load failed.
E: [(null)] daemon/main.c: Failed to initialize daemon.
W: [(null)] pulsecore/core-util.c: Secure directory creation not supported on Wi
n32.
It appears that the installation fails; how do I remedy?
I'm having similiar error messages. Did you find a solution?
i know this post is years old but i just had this problem and there’s no other reference showing up in my google searches.
however, for future google searchers….
this appears to be a bug that is caused by disabling microphone input in recording devices on windows. In my case, re-enabling my microphone resolved the issue.
bug links;
https://www.cendio.com/bugzilla/show_bug.cgi?id=4119
https://www.cendio.com/bugzilla/show_bug.cgi?id=2831
Hi. can you tell me where exactly I can find the .xsession file please? I am using RDP on XP to connect to Linux Mint using XRDP and can not find .xsession anywhere. Do I have to create this file? If so, how?
Stan,
The
.xsession
file should be created when you run the RDPsesconfig tool after X11RDP-o-matic. Its location should be in the home directory of all users selected when you run the tool.Regards.
@Dismayed User
edit c:\pulseaudio\etc\pulse\default.pa
change the line where waveout module is loaded and add record=0. That fixed it for me.
load-module module-waveout record=0 sink_name=output source_name=input
greetz
Klaus
In general I’ve observed that audio is playing good (local server) except one thing: FLASH !!
You can check it if you switch your browser to HTML5 (http://www.youtube.com/html5). Most videos are playing excellent in HTML5.
greetz
Kevin…
I noticed in your article Sound with xrdp/X11RDP that your writeup describes using TCP?
I checked Pulseaudio and it looks like it only implements TCP and no UDP option
I wonder why they never implemented a UDP connection for audio since audio is generally one-way you are only concerned about dropped pkts causing delays (possibly due to TCP retransmissions). With udp you might drop a few pkts now and then but most people may not hear the difference in the audio. Pulseaudio’s site did mention they support RTP for audio.
Brian,
Interesting that. This article is kind of getting a bit redundant, now that xrdp has a pulseaudio sink of it’s own. I might do a write-up about it in the near future. It’s a little bit involved and I haven’t properly read it over, yet.
Regards!
I am trying to get this working with Windows 7 client (my server is Ubuntu 13.04). When I went through the steps, I got the same kind of screen output as that shown here idicating that the PulseAudio daemon loaded. I also checked that the sound settings on the Windows side were for playing sound on the local system rather than the server. On the remote session, I did not see any audio device representing the Windows system in Sound settings and there was no sound. I did see some errors in my syslog as follows:
Mar 24 21:25:47 Pegasus pulseaudio[2553]: [alsa-sink] alsa-sink.c: Error opening PCM device front:0: Device or resource busy
Mar 24 21:25:47 Pegasus pulseaudio[2553]: [pulseaudio] sink-input.c: Failed to create sink input: sink is suspended.
Based on the recent comment concerning the fact that xrdp has a pulseaudio sink of its own, I rebooted, installed PulseAudio Preferences and changed settings by guesswork:
Checked Enable network access to local sound devices
Checked Allow other machines on the LAN to discover local sound devices
Checked Enable Multicast/RTP sender
Checked Create separate audio device for Multicast/RTP
I started remote session but without manually starting pulseaudio daemon as before. Running ps -ef indicated that pulseaudio was already started through startup anyway (perhaps reason for errors above). I didn’t get any errors in syslog now but still no audio device shown in Sound settings on remote session and no sound.
From PulseAudio Manager, my server version is 3.0.
Hoping you might be able to help,
Alvin
Just noticed I was getting a little confused over running of PulseAudio. In the last test, I had not started pulseaudio on Windows side so I guess it wouldn’t work. I just tried again with starting the daemon on the Windows side and I also checked the Enable Multicast/RTP receiver in PulseAudio Preferences on the linux server in case that applies, but I still get the same symptoms of no audio device listed and no sound in the remote session.
Alvin
Hi,
You are maybe running it on a rdp (a virtual machine it doesn’t support input) so the output is your pc (remote).
so pulseaudio cannot find a device.
try directly on your host to be sure.
Thanks for replying. I am running RDP in exactly the same way as described in this article with a Windows client. I’m not sure what you mean by a virtual machine in this context.
I certainly have my doubts about pulseaudio capabilities as I ran into problems trying to use Teamviewer as an alternative solution and was not able to get the audio sending for that either. I have the latest version of pulseaudio but I read about so many problems with it and I wonder if I am fighting a losing battle here.
Hello and thank’s for your work !
(Sorry for my english, i’m french…)
I have installed xrdp on a debian machine and i connect to it with 4 xp machines. It is running fine but i have no sound, so i read your tuto, but i don’t find .xsession file. I just find /etc/X11/Xsession. Can you tell me what i have to do ? ( i’m a beginner in with Linux)
Thank you for your help
cyril
Hi
Any ideal how to have Macbook pro connected ubuntu with sound?
I install pulseaudio but it wasn’t listen to 4713
Thanks
Got pulseaudio listening to 4713 on macbook pro, ubuntu is connected to it via 4713. But no sound on macbook :(
[…] xrdp “Using Windows RDP to Access your Ubuntu Instance | Cloud Services” “xrdp pulseaudio sink and source“なんて記事があるところをみるとデフォルトでは音の送信はサポートされてない模様。”Get audio with your xrdp/x11rdp connections, LAN or Remote! Updated! Windows Clients! – Scaryg…” Windowsホスト側にPulseaudioをインストールして実現する方法。大変そう。 […]