12.3.  Using Sound Device Redirection

12.3.1.  Introduction

With ThinLinc, it is possible to access the client's sound device from the ThinLinc session. This means that you can run sound applications on the remote desktop servers and listen to the sound through the client's sound device and speakers. Input devices such as microphones can also be used.

12.3.2.  Requirements

  • EsounD client libraries to support applications with native EsounD support.

  • esddsp to support OSS applications via EsounD.

  • PulseAudio client libraries to support applications with native PulseAudio support and the ALSA plug-in. ThinLinc supports version 0.9 of PulseAudio.

  • padsp to support OSS applications via PulseAudio.

  • alsa-plugins, version 1.0.12 or later, to support ALSA applications via PulseAudio.

12.3.3.  Using sound redirection with UNIX applications

ThinLinc can support sound redirection for almost all applications, provided that the correct libraries and utilities are installed on the ThinLinc server.

12.3.3.1.  EsounD applications

All applications that can communicate using the EsounD protocol will work automatically in ThinLinc. Most modern multimedia applications support EsounD, meaning that the only required work is to make sure they use EsounD by default. Unfortunately, EsounD does not work well for users running multiple ThinLinc sessions.

12.3.3.2.  PulseAudio applications

All applications that can communicate using the PulseAudio protocol will also work automatically in ThinLinc. Most current distributions are configured to use PulseAudio by default, but older ones might require some configuration to work properly.

12.3.3.3.  OSS applications

Most applications that use the Open Sound System (OSS) can be made to work with ThinLinc through the esddsp or padsp application.

padsp redirects OSS applications to the PulseAudio protocol. The following command line should be used:

padsp <application>

See the padsp manual page for more information.

esddsp redirects OSS applications to the EsounD protocol. The command line is similar to padsp but requires an extra -m to enable mixer emulation:

esddsp -m <application>

See the esddsp manual page for more information.

The application which communicates with the sound device must be dynamically linked to glibc. It is not possible to intercept the accesses to OSS in a statically linked application. Most applications that you find on a Linux system will satisfy this requirement, but a test with ldd can also be done:

$ ldd /usr/bin/someapp
        not a dynamic executable

When using esddsp or padsp on 64-bit platforms, make sure that you have both 32- and 64-bit versions of the necessary libraries (libesddsp.so.0 and libesd.so.0 for esddsp , libpulsedsp.so and libpulse.so.0 for padsp ). Usually, these are found in /usr/lib and /usr/lib64. Also, the esddsp and padsp scripts must not contain absolute references to these libraries. Instead, the system should automatically select the correct library, depending on if you are executing a 32- or 64-bit application. In this case it's necessary to have both library directories included in /etc/ld.so.conf.

esddsp has a bug which require you to create some files in /tmp in order for it to work. Execute the following as root:

mkdir /tmp/.esd
touch /tmp/.esd/socket

Many distributions clean out /tmp periodically so this procedure should be added to that script or repeated as necessary.

Although it is rare, some applications manage to misuse the OSS API in a way that works with local sound cards but not esddsp or padsp . If you encounter problems, try updating the application to the latest version as it might contain fixes for such bugs.

12.3.3.4.  ALSA applications

All applications that use the Advanced Linux Sound Architecture (ALSA) will also work well with ThinLinc provided the correct plug-ins are installed and configured. The plug-ins can be found in the alsa-plugins package (called libasound2-plugins on Debian-based distributions). The PulseAudio client libraries are also needed to build and use the plug-ins.

To redirect ALSA applications to use the plug-ins, the ALSA configuration must be modified. This can be done on a global level in /etc/asound.conf or per user in ~/.asoundrc. Add the following to the file (creating it if necessary):

pcm.!default {
    type pulse
}
ctl.!default {
    type pulse
}

Unfortunately, there are some applications that use the ALSA API in an incorrect way. When using local hardware this usually doesn't matter, but when advanced ALSA features, like dmix or this plug-in, are used, then problems start to appear. If an application misbehaves, the first step should be to upgrade it to the latest version. With some luck, the API is used more correctly in a later version.

12.3.3.5.  Choosing sound system

Many applications support several sound systems and it can be difficult to know which one to use. The general principle is to choose a PulseAudio solution over a EsounD one at all times.

Applications should be configured in the following manner, listed from the best solution to the worst:

  1. Native PulseAudio application.

  2. ALSA appliction using the PulseAudio plug-in.

  3. OSS appliction using padsp .

  4. Native EsounD application.

  5. OSS application using esddsp .

12.3.4.  Using sound redirection with Windows Remote Desktop Servers

It is possible to use sound redirection with applications running on Windows Remote Desktop Servers, via RDP. This is controlled by the parameter /appservergroups/rdp/<group>/sound . For more information, please refer to Section 14.2.4, “ Parameters in /appservergroups/ ”.

To use input devices with applications running on Windows Remote Desktop Servers, it is necessary to use the ThinLinc WTS sound driver. See Section 3.7, “ The ThinLinc WTS Tools Package ” for more information.

12.3.5.  Limitations and additional information

  • Transferring sound over the network requires a lot of bandwidth, so it is only suitable for high-speed networks, such as LANs.