Introduction

Citrix Workspace app (formerly Citrix Receiver, Online Plugin, ICA Client, etc.) for Linux is a popular client for accessing Citrix Virtual Apps and Desktops (formerly XenApp and XenDesktop). It is particularly popular due to the proliferation of “Zero OS” or “Thin OS” Thin Clients which are predominantly Linux-based. Offerings from HPE, IGEL, Dell Wyse, NComputing dominate this category in addition to a number of smaller Thin Client players who have adopted Linux as the underpinning OS. Many of these vendors derive their Citrix Workspace app (CWA) for Linux software right from Citrix, while others (of note Dell Wyse up until ThinOS 9 I believe, after which they made the switch) would construct their own CWA for Linux variant, often lagging behind feature sets of the current Linux client available.

With that said, Citrix’s engineering teams for CWA innovate features first on Windows, followed in second priority by Linux and Mac, and finally the mobile variants. The following diagram from our recent HDX Multimedia webinar with Citrix Product Management illustrates this flow.

What this means for administrators and organizations, is some features that exist in Windows may take a while to show up in lower priority client platforms. For this reason, it is critical when evaluating Thin Clients and endpoints in general, that customers and consulting partners review the Citrix Workspace App Feature Matrix which is a living document and is regularly updated as features are introduced into the various client platform releases.

Although many organizations prior to the 2020\2021 global pandemic had work from home strategies in place for years, many were forced to abruptly adopt remote work expanded beyond the norm, or for business units that had little to no remote work strategies prior. This created chaos amongst IT management and security teams in many organizations, and growing pains for both users and management alike.

During this period, numerous organizations had to spend hundreds of thousands, if not millions, on remote work strategy expansion and in order to optimize costs, the often lower-priced Linux-based Thin Clients were selected over their Windows brethren. Although fantastic options, at the time of this article’s creation, there is a notable disparity in the voice and video capabilities of CWA for Windows and CWA for Linux.

In particular, audio over UDP is available for CWA for Linux clients directly connecting to a Citrix VDA, however, this does not extend to CWA for Linux through a Citrix Gateway (via Citrix Gateway service or customer-managed Citrix Gateway). This is understandably a concern for customers who have invested in Thin Clients for work-from-home use cases, in particular for customers who depend on VoIP technologies such as call centres.

For clarity, when referring to audio over UDP, I am referring to audio optimization within the ICA channels via HDX Multimedia. This is the inbuilt Citrix optimization capabilities for audio that are leveraged if a softphone, VoIP app, or unified collaboration platform used in a Citrix environment does not have its own optimization capabilities that manage voice and video outside the ICA channels. Audio over UDP is an advancement over TCP audio optimization in Citrix, which uses the RTP protocol which although being UDP-based, is a reliable protocol for this medium.

Although some customers can reap some of the benefits of UDP audio in Citrix through the EDT protocol (aka HDX Adaptive Transport), Citrix-optimized UDP audio with EDT remains preferable as EDT on its own has a custom flow control and congestion architecture that is not optimized for VoIP as outlined in “EDT and Audio” in CTX133024.

For many customers during the pandemic, it has become critical to tune Citrix and Thin Client platforms to optimize Citrix HDX Audio over TCP, the mainstay medium for Citrix Audio for decades. And properly tuned, customers can achieve a user experience, not unlike the UDP variant, last-mile (ISP to end-user and end-user home network conditions) considerations aside. This is a topic we’ve written about previously at Ferroque.

Now that I’ve humored my standard habit of long-winded introductions, let’s get onto the optimizations. I’ve organized these optimizations into server-side and client-side optimizations. These are recommendations we made recently in our HDX Multimedia webinar series, but I figured this warranted a more detailed review. The server could be a single-session or multi-session OS VDA (OS type agnostic, and we will assume the VDA is Windows-based).

Server-Side Optimizations

Once again, the key assumptions here are:

Windows-based VDA
VoIP application which does not have an optimization pack capability for Citrix environments that remove audio from ICA channels, and thus rely on inbuilt audio optimizations from Citrix
The CWA client is presumed to be Linux-based over a Citrix Gateway, so HDX policies for UDP audio and RTP are being excluded from recommendations
CPU specifications are no less than 3vCPUs for a VDI (we have in numerous HDX multimedia scenarios that regardless of the endpoint, 2 vCPUs does not cut it, moving to 4 vCPUs helped cut down on choppiness and robotic sound). Citrix has been recommending 4 vCPUs for Windows 10 1803 and higher for several years due to added CPU load (which may or may not show itself in CPU trends). One might argue that 2 vCPUs is fine for a very “light” workload, but I’d have to argue that HDX audio use cases are likely not light

These recommendations are straightforward and are largely derived from existing Citrix articles on the subject.

Set the audio quality in HDX policies to Medium or Low. Low for many use cases may in fact suffice, subject to testing. Do not go beyond Medium quality, however (default is High by the way) as High lacks the echo cancellation capabilities (and for UDP\RTP audio use cases, Medium or lower is also mandatory FYI).
Configure the CPU priority of the “Citrix Audio Service” on the VDA to operate in “Realtime” with regards to the service’s CPU priority. As my colleague Jeff Qiu outlines in his Citrix Blog on VoIP performance optimization, it is necessary to perform this either as a startup script or via WEM. In one customer environment, we found this was changing back on its own and had to run a scheduled task that maintained the desired priority.
It may be necessary to alter the TCP profile of the Citrix Gateway in testing. The default XAXD profile is a starting point recommendation for being bound to a Citrix Gateway, but it is not optimal for all environments and use cases. For offshore users, we often have to tune a custom TCP profile to improve their experience. Going off on a tangent… depending on whether EDT is being used, Nagle may need to be toggled on the profile as well. Nagle has now been disabled on modern Citrix ADC firmware versions on the default XAXD profile as being HDX Adaptive Transport\EDT is the preferred protocol for HDX delivery, the Nagle algorithm isn’t suitable. If not using EDT, clone the profile and keep Nagle enabled. Back on track, we found with one customer using Linux Thin Clients that the default “WAN” TCP profile actually yielded a better VoIP experience than the default XAXD profile or one of our standard “tuned” profiles we recommend. In any case, test, test test. We found HDX Insight to be invaluable in validating the efficacy of a TCP profile by the numbers, not just by user feedback.
If using Microsoft Teams, be sure to install the 32-bit version of Teams in the VDA otherwise audio and video will fall back to HDX audio and webcam optimization due to current limitations with Linux. Being Teams Optimization is preferable to the HDX optimization capabilities within ICA channels, heed this advice if Teams is the VoIP \ Unified Communication app in use.

Client-Side Optimizations

The key assumptions here are:

Linux-based endpoints and Thin Clients
Endpoints access Citrix resources via a Citrix Gateway for secure ICA proxy. I.e. CWA has no direct access to the VDAs, thus fall back on audio over TCP

Linux OS \ Thin Client

Tune pulseaudio within the OS to control audio and microphone sound. Depending on the vendor, it may be represented as a time buffer or a bandwidth buffer. Examples:
- Dell Wyse ThinOS clients represent this control as a time buffer. It is toggled via the “min_cache” parameter of its INI configuration file. We recommend setting it to the maximum available parameter which is 0.5 seconds. The default value is 0, we suggest setting this parameter to 50 in the INI which translates to 0.5 seconds
- HP (see pg. 79) ThinPro clients control pulseaudio via a bandwidth buffer control, which is set to 1.5Mbps by default through the “PulseBuffer” parameter. Tune and test this value in 0.5-1MB increments. The parameter allows for 1024-8192 KBPS but HP warns setting the value too low may crash the Thin Client, while setting too high (i.e. 8MB) may increase jitter during playback.

Citrix Workspace App

Configure the “Audiolatencycontrol” parameter to “True” in the CWA module.ini file. This is an often-overlooked setting that isn’t widely talked about but was introduced many years ago in the Linux Citrix clients. Details on this setting and its affiliated latency correction settings can be found in the Citrix Workspace app for Linux OEM Reference Guide.
(Optional) One the above parameter is enabled you can tune various latency controls if the default proves insufficient in testing. Reference Citrix Workspace app for Linux OEM Reference Guide for details under “Configure audio latency correction”.
- PlaybackDelayThresh, specify the initial level of output buffering in milliseconds. Workspace app tries to maintain this level of buffering throughout a session’s duration. (Default 150ms).
- AudioMaxLatency, specify the maximum latency in milliseconds to allow before Workspace app attempts to discard audio data. (Default 300ms)
- AudioTempLatencyBoost, sets the amount by which the higher latency band is above the lower. (Default 300ms)
- AudioLatencyCorrectionInterval, specify how often we want to attempt to correct the latency in milliseconds. (Default 300ms)

Additional Considerations

If despite optimizations UX remains poor, there is likely last mile issues at play. You may gain some benefits with UDP audio which can be achieved through various means, but VPN should be discounted early on. Not only do most Thin Clients support a very limited set of VPN capabilities, but many also don’t support UDP as a traffic medium. VoIP over traditional client VPN is a common recipe for terrible UX.

Organizations tend to lack control over the ISP link capabilities (broadband bandwidth, offerings in a given geolocation, etc.), let alone the conditions within the user’s home (poorly tuned WiFi networks, network congestion from two adults working, kids gaming\streaming\schooling).

The best option, in this case, is an SD-WAN platform tailored to remote users such as Citrix’s SD-WAN 2xx and 1xx devices. With the ability to securely tunnel into the corporate network and provide link redundancy between the user’s ISP and an LTE network, the reliability, performance, and security of a corporate user’s endpoint can be increased dramatically. There is an uptick in cost and infrastructure here to be sure, but the benefits may very well strongly outweigh the investment and pay for themselves in short order when accounting for lost productivity or brand impact from dropped calls and degraded productivity.