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. Contact Cendio for an unofficial and unsupported patch to remedy this problem.

alias net-pf-10 off

All applications that can communicate using the PulseAudio protocol will also work automatically in ThinLinc. This is a new protocol so few applications currently support it. It is technically superior to the EsounD protocol though, so support is likely to increase.

The PulseAudio protocol is still under development so not all versions can be supported at the same time, although we try our best to stay compatible. Currently version 0.8 to 0.9 have been tested and are supported.

Polypaudio was the former name of PulseAudio. As such, the two are completely protocol compatible. The name change, however, meant that they use separate configurations. The current version of ThinLinc configures the system for both, but future versions will require manual configuration to support the older Polypaudio 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.

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 (or Polypaudio when using alsa-plugins 1.0.11) 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
}

If you're using the older Polypaudio based version, replace "pulse" with "polyp".

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.

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. As PulseAudio is a very recent addition to the Linux world, you might still be forced to use EsounD though, as PulseAudio isn't shipped with your distribution.

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