Following my recent post regarding Silverlight, unfortunately I have hit disaster.  When the audio starts, it sounds choppy with a double-echo or reverb.  In short it is unusable.  All other audio works fine, even on the same webpage, but as soon as you try and listen to a Silverlight widget it sounds terrible.

Googling “silverlight rdp choppy” in desperation has not filled me with confidence, there are a number of posts including:

• Has anyone else ran into a problem where if you use a Silverlight app over Remote Desktop and it plays a WMA or MP3 file using MediaElement, the sound is choppy?

It is possible that upgrading to Windows Server 2008 would resolve this issue; although there are issues I believe in connecting to the latest RDP version using rdesktop.

I did find this advice from Microsoft, the Microsoft RDP Client was the only sound card available, but I followed the advice anyway to no avail.

What I simply do not understand is why all other audio works perfectly via RDP, except Silverlight, especially given the fact that Silverlight and RDP are Microsoft products.

Any suggestions gratefully received!

We have to be able to play Silverlight media on our two virtual Windows Server 2003 servers.  This is completely unavoidable, because you first need to authenticate via an Active-X website, so any option of using Moonlight on Linux was impossible.

The problem that we had was that when we clicked on the Play Media button, there were two pop ups stating “This page has an unspecified potential security risk” followed by another stating “A problem was encountered with the media file specified.”

I tried bypassing our proxy server;  I ensured that the Internet Enhanced Security was uninstalled; I tried adding the relevant sites to “Trusted sites”; I tried reducing Trusted Sites to “Low” security; I brought all the critical updates up-to-date.  Nothing seemed to make a difference.

Finally, I decided to review the optional Windows updates, just to see if there was anything related to Silverlight and noticed that there was a major update to .net available “.NET framework 4”. Knowing that Silverlight is a .net technology, I installed it and, after yet another reboot, the pop ups had gone and it was working.

My reason for writing about it is simply this:  I had googled endlessly about this problem, without any success, there was seemingly nothing relevant to this problem.  Hopefully this post will help others.

But you should be using Linux not Windows!  There, couldn’t resist ;)

FreeRDP is a fork of the rdesktop project that intends to rapidly start moving forward and implement features that rdesktop lacks the most.

For more information please visit:

• FreeRDP.

Cendio SeamlessRDP

The Cendio SeamlessRDP component has two halves, a Windows executable as the “server component” for installation on the Windows server, and patches to the rdesktop application, to work with the server component. At the time of writing, these Cendio patches have now been merged into the rdesktop 1.5.0 and later core.

• You can download the source using Subversion.
• You can get a binary and unzip the files into c:\seamlessrdp (or similar).

Once you have a binary on your Windows server, then from you Linux client, type:

$ rdesktop -A -s "c:\seamlessrdp\seamlessrdpshell.exe notepad"

Under W2K8, both seamlessrdpshell.exe, and the Windows application you wish to run with it, must be published terminal services applications. And seamlessrdpshell.exe must have command line parameters enabled, by running “TS RemoteApp Manager’s” “Add RemoteAppProgram” dialog (remoteprograms.msc).

Fontis SeamlessRDP

Fontis have further developed Cendio SeamlessRDP, to enable connection sharing, allowing a single rdesktop connection to launch multiple applications. When run in seamless mode, rdesktop creates and listens on a control socket. A new option allows rdesktop to be run in slave mode, which notifies the master rdesktop instance of a new command to be run and then exits. The master instance sends a client-to-server message to the SeamlessRDP server component, which runs the new command.

I see this development as fairly fundamental to the use of SeamlessRDP.

Installation of Fontis patch

Download source for the latest version of rdesktop from CVS (press enter when prompted for a password):

$ cvs -d:pserver:anonymous@rdesktop.cvs.sourceforge.net:/cvsroot/rdesktop login
$ cvs -z3 -d:pserver:anonymous@rdesktop.cvs.sourceforge.net:/cvsroot/rdesktop co -P rdesktop

Alternatively, download the rdesktop CVS snapshot which has been tested with the patch. Download the rdesktop patch to the checked out directory:

$ cd rdesktop $ wget http://www.fontis.com.au/system/files/rdesktop.patch

Apply the patch and compile:

$ patch -p1 < rdesktop.patch
$ ./bootstrap
$ ./configure
$ make

Download updated server component and unpack. Alternatively, obtain the seamlessrdp CVS snapshot or download direct from CVS, apply the seamlessrdp patch and then compile:

$ cvs -z3 -d:pserver:anonymous@rdesktop.cvs.sourceforge.net:/cvsroot/rdesktop co -P seamlessrdp
$ patch -p1 < seamlessrdp.patch

Usage

The following examples assume the SeamlessRDP server component files (seamlessrdpshell.exe, seamlessrdp.dll and vchannel.dll) have been unpacked to C:\seamlessrdp. To start a SeamlessRDP session, invoke rdesktop in the same way as before applying the patch:

$ ./rdesktop -A -s "C:\seamlessrdp\seamlessrdpshell.exe notepad" server

To run a new command inside the existing SeamlessRDP session:

$ ./rdesktop -l "calc"

New command-line options:

• -M: Specify the path for the control socket that the rdesktop process listens on. By default, this is $HOME/.rdesktop/seamless.socket
• -l: Instead of starting a new rdesktop process, connect to an existing process’ control socket and tell it to run a command on the server. Can be combined with the -M option to use a non-standard socket.

Background

Rdesktop is a problem, because it uses /dev/dsp as the sound device (for version 1.5 at least). This is incompatible with ALSA.

Solution

Specifying “oss” as the sound driver, instead of the default, worked fine:

$ padsp rdesktop -r sound:local:oss 192.168.0.1

Further to my recent post, it transpired that rdesktop uses /dev/dsp which is incompatible with alsa. Specifying “oss” as the sound driver, instead of the default, worked fine.

$ padsp rdesktop -r sound:local:oss 192.168.0.1

This is apparently because rdesktop version 1.5 does not support alsa, but still uses /dev/dsp as the sound device. A new version 1.6 of rdesktop is now available (albeit not in the debian etch or etch-backports repositories), which should address this issue. Unfortunately we are using a patched version of rdesktop, provided by fontis, and I know they were struggling to integrate their patches into the latest versions. I should probably attempt to contact them at some point.

This also represented my first attempt at using IRC #ltsp - which proved invaluable. Installed Konversation, as I could not get on with Kirc.

Today I discovered that since our upgrade to LTSP5, sound has stopped working in rdesktop sessions. Worse, it bombs users out of their Windows session with the error:

rdesktop: pcm_params.c:2351: sndrv_pcm_hw_params: Assertion `err >= 0' failed.
Aborted

Under 4.2 it was working beautifully simply by prefixing rdesktop with esddsp, e.g.

$ esddsp rdesktop -r sound:local 192.168.0.1

But removing esddsp or replacing with padsp causes exactly the same error message. I suspect with alsa the esddsp/padsp fix is no longer required, but why does it not work?

I have even tried pointing padsp at the client pulseaudio device…

$ padsp -d -s 192.168.0.41:4713 -n rdesktop rdesktop -r sound:local 192.168.0.1

I have posted this as a question on the LTSP Mailing List and am hopeful of a solution!