Editor's note: this article is out-of-date, as VMware finally ported the Horizon Client RTAV extension to ARM Linux starting from version 2106 (TLXOS 4.10.1 provides 2111).
Unfortunately, for reasons beyond ThinLinX's control, this is difficult, and in many cases impossible. USB audio redirection is the only available option, and this is unsafe and unreliable.
The Raspberry Pi has no onboard microphone capability, because it lacks hardware for this, and the additional pin on the analog audio jack that is typically used for audio input is used for something else entirely (composite video output). So plugging an analog earbud-with-microphone into this will not work (you will get playback only, no microphone).
Under normal circumstances, you could use a USB headset to provide bidirectional audio, but unfortunately the Linux ARMHF port of Horizon Client lacks the Real Time Audio Video (RTAV) extension that is required for microphone redirection, and that every other Linux port of Horizon has. There is nothing that ThinLinX can do about this, as we do not have access to the relevant Horizon Client source code (we have access to the source code that provides the application-browser part of Horizon Client, but the actual rendering engine is strictly proprietary). We have complained to VMware about the missing RTAV extension, which we think they could port to Linux ARMHF very easily, but they regard the Linux ARMHF port as "unofficial" (there is no mention of the port in any of their product documentation other than release notes) and are unwilling to invest any further time in it until there is "more customer interest".
This means that the only way to redirect a (USB) microphone to a remote Horizon session is to use USB redirection. Normally, USB redirection policy bans redirection of devices in the USB Audio class, because this can potentially conflict with high-level audio playback redirection (core capability that the Pi client has) and RTAV (which the Pi lacks) due to device contention, i.e. the Linux client and the Windows server both try to control the audio hardware directly, each without knowledge of what the other is doing, and get unexpected results. But because it's the only possible option, ThinLinX have provided an alternative default USB redirection policy stance that allows redirection of Audio class devices - "Auto with audio redir (risky)" - for the Raspberry Pi only. See http://help.thinlinx.com/knowledgebase.php?article=50 for more information on this.
Using this alternative policy, it is sometimes possible to get bidirectional USB audio to work in a remote Horizon session. We have only tried this on a very few USB audio devices, and it works for some hardware (e.g. my Microsoft LX3000 headset) and not others (e.g. my boss' Logitech H340 headset). When it doesn't work, you typically get no audio playback as well as no detectable microphone. It might also cause the Horizon session to freeze or crash.
« Go back