VMware Horizon Community
szilagyic
Hot Shot
Hot Shot
Jump to solution

Issues with audio/video streaming with USB devices on zero clients

Hello:
We are using View 6.1.1 in our environment and having issues getting audio/video streaming to work well with USB headsets, with zero clients.  The headsets are Jabra Link 360 and the zero clients are Samsung NC241.  The headsets are used both for phones in Jabber, and also as the default audio device.   We started by using the Teradici audio driver and everything seemed to work well except that users could not answer calls on the headset itself with the button on the headset.  They were able to answer calls from within Windows however and that part worked fine.  In order to get the physical button working, we had to first bridge the USB receiver that they use on the zero clients so Windows would see it as the Jabra 360 device and not the Teradici audio device.  Then we had to enable EHCI mode for USB on them as well, and after that it started working fine.  However, the headsets are also used as the primary audio device as well as the communication device (phone), with audio streaming continuously throughout the day.  With the current setup, the audio streaming will cut in and out during the day, and audio/video is not always staying in sync either.

I have also applied the registry hack in this KB, VMware KB: Improving audio quality when using USB headsets or speakers with a VMware Horizon View 5.... , which helped clear up crackling that we initially had with the phone part of the headsets.  But the issue of audio streaming persists.

I am wondering if the efficiency of bridging USB is not as efficient, and also is there a way to make this work better?  I have read that using the Teradici driver is supposed to help with audio/video problems, but not sure how that may apply to USB devices like we are using.  I have been reading up on the audio/video Teradici settings, but am not sure where to go from there.  I was hoping that there were some best practices to using USB headsets with View, but so far I'm not finding anything helpful.

Any help or suggestions would be greatly appreciated.  Thanks in advance.

1 Solution

Accepted Solutions
szilagyic
Hot Shot
Hot Shot
Jump to solution

We ended up finally getting help from the Cisco folks after posting in here and even opening a support ticket with VMware which was open for over a month without resolve.  In case others are trying to set up similar, here are our findings:

  • Zero clients combine USB and PCoIP traffic.  This is no good when there is a lot of audio/video/USB traffic, especially USB headsets that also carry softphone audio.  In our case, the USB traffic was so dense that it was causing audio/video to become choppy and freeze, and eventually causing the pcoip_server service to crash in the VM itself and cause the client to disconnect.  The fix?  Do not use zero clients with USB softphones, they just aren't meant for this type of solution.
  • Thin clients are much better designed for using USB softphones.  In our case we used the Cisco VXME client which is the supported method for using Windows thin clients with the Horizon client.  There is some integration between the two products that isolates the VOIP traffic out of the VM and keeps it local on the thin client itself.  Regular audio and video traffic still go through the VM using the Teradici or VMware RTAV driver.

Hopefully this helps others that may run in to this issue.  One thing we did not try was a wired headset that uses the AV jacks on the zero client, and the Teradici audio driver.  This may work but our requirements here were that the headsets must be bluetooth so we were forced to stick with USB.

View solution in original post

2 Replies
szilagyic
Hot Shot
Hot Shot
Jump to solution

Another issue that has come up is that inside of the session itself, in the user's Windows VM, the audio settings stop working as well.  For example, audio on the headset will start cutting in and out and eventually stop working.  The user is going in to windows control panel, to Sound, and verifying that the headset shows up and is set as the default Playback and Recording device.  Even if they change this setting, it does not work until the user locks their Windows session (in the VM) and unlocks it, then all of a sudden the audio works correctly with the device selected in Windows.

That too has us stumped.  We were hoping for a simple answer with these symptoms but so far no luck in getting this figured out entirely.

If anybody has any possible information to add, mainly best practices for using USB headsets with zero clients, that would be awesome.

Thanks in advance.

Reply
0 Kudos
szilagyic
Hot Shot
Hot Shot
Jump to solution

We ended up finally getting help from the Cisco folks after posting in here and even opening a support ticket with VMware which was open for over a month without resolve.  In case others are trying to set up similar, here are our findings:

  • Zero clients combine USB and PCoIP traffic.  This is no good when there is a lot of audio/video/USB traffic, especially USB headsets that also carry softphone audio.  In our case, the USB traffic was so dense that it was causing audio/video to become choppy and freeze, and eventually causing the pcoip_server service to crash in the VM itself and cause the client to disconnect.  The fix?  Do not use zero clients with USB softphones, they just aren't meant for this type of solution.
  • Thin clients are much better designed for using USB softphones.  In our case we used the Cisco VXME client which is the supported method for using Windows thin clients with the Horizon client.  There is some integration between the two products that isolates the VOIP traffic out of the VM and keeps it local on the thin client itself.  Regular audio and video traffic still go through the VM using the Teradici or VMware RTAV driver.

Hopefully this helps others that may run in to this issue.  One thing we did not try was a wired headset that uses the AV jacks on the zero client, and the Teradici audio driver.  This may work but our requirements here were that the headsets must be bluetooth so we were forced to stick with USB.