Using Sound Device Redirection¶

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.

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

Requirements¶

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.

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.

OSS applications¶

Most applications that use the Open Sound System (OSS) can be made to work with ThinLinc through the 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.

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 padsp on 64-bit platforms, make sure that you have both 32- and 64-bit versions of the necessary libraries (libpulsedsp.so and libpulse.so.0 ). Usually, these are found in /usr/lib and /usr/lib64. Also, the padsp script 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.

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

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.

Choosing sound system¶

Many applications support several sound systems and it can be difficult to know which one to use. Applications should be configured in the following manner, listed from the best solution to the worst:

Native PulseAudio application.
ALSA appliction using the PulseAudio plug-in.
OSS appliction using padsp .

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.