jroback
Enthusiast
Enthusiast

Audio problems with RTAV in video conferences

We're really struggling to get a good experience out of Horizon view for video conferences.  (Horizon 7.x  on Windows 10 VMs, using PCOIP across the Internet with Windows Horizon Clients). 

We've got RTAV going with PCOIP (not extending mic or camera via USB)  and that is making the video work reasonably well, but where we're really struggling is the audio.  We did use group policy setting "Configure the PCoIP session audio bandwidth limit" to increase audio receive quality as mentioned in KB 2045764.  And we found that going into the microphone properties for the RTAV device on the VM, we are able to increase the microphone sample rate to 16K, which helped a lot.  So we though we were all set.... but then realized the microphone resets to 8K on each reconnection.    We then found KB article 78402 which points out that by design for backwards compatibility, which really kind of killed my excitement.

The KB is kind of frustrating because the "expected behavior" explanation implies this isn't a big deal and won't change.   But this isn't just a question of the audio not sounding great… what we're finding is that the echo cancellation in video call software isn't working right with the 8K microphone stream, and so everyone on the calls is hearing echos and clicks from the RTAV participants.  These issues decreases dramatically when we turn it up to 16K.

Unfortunately, setting the rate change requires many clicks in Windows, and so isn't something we can ask end users to do for every call, so if we can't automate it, we can't use it. I've done some tracing with process monitor, etc, to try to track down what is changing when we manually move this to 16K, but it seems buried deep in the registry under instance specific GUIDS, and not something we can easily automate.

Does anyone know if VMware plans to allow us to control this with Group Policy at some point?  Or has anyone found a way to automate this?   I've even though about hitting windows API's via powershell, but that seems like a black hole too.

For now we've had to resort to suggesting users do their video conferences outside of Horizon, which I really hate to do because it becomes a slippery slope back to them wanting a full client locally.

17 Replies
bjohn
Enthusiast
Enthusiast

Sorry to hijack this thread, but wondering if you seen this. We have issues with RTAV, where the microphone suddenly stops working. What happens is that all of the sudden there is no output from the microphone. I can still hear thru the headset, but what I’m speaking is not heard by others.

I have to disconnect/reconnect the session and disconnect/reconnect the headset for it to work again.

0 Kudos
JoshJames
Contributor
Contributor

I have the same issue.  The echo makes RTAV unusable with Google Meet.  It does seem to be less of an issue with application based Zoom.  What conference tool(s) are you testing with?    I don't have HTML5 redirection set up, not sure if it will help...

0 Kudos
jroback
Enthusiast
Enthusiast

We're seeing this with Lifesize, as this is our platform of choice, but I would think it would occur on any platform that is using RTAV for audio.   Microphone will always revert to 8K sample rate on login per kb.vmware.com/s/article/78402

What's frustrating is that VMware has forced the default on this to 8K, and Microsoft appears to have purposely blocked any attempt to change the default by anything except the gui,  But even if we have the user change it by GUI, Vmware resets it on the next logon.   Microsoft has blocked  Powershell and API commands from changing this so that the end user gets to decide this setting.    So we're stuck with having to live with 8K or instruct users to change this themselves for each login, neither of which is a great answer.

I can understand VMware wanting to maintain backward compatibility per the technote, but if they could just give us a registry entry to override this, they could immediately improve the audio experience of people using VDI for video conferences.  If you look through Reddit, you'll see that the geneeral consensus of IT folks having to support video conferences through VDI is "Don't".   They're directing users to run their sessions outside of VDI, which leads folks down a road that's hard to get back from.

Something I've wondered about is using RTAV for video and forcing microphone and speaker output to use the non RTAV driver... but this seems like it would be setting things up for bad sync issues.

Would be very interested to hear if others have found the magic solution for making video conferences work well in Horizon.

0 Kudos
ofox
VMware Employee
VMware Employee

It's hard to tell w/o further debug or looking into logs.

0 Kudos
ofox
VMware Employee
VMware Employee

Thanks for the issue report.

The KB is right that the default sample rate is 8KHz and changing it to 16K would not persist across sessions. Since MSFT only allows to change it via deivce UI setting manually, at the moment we're not aware of an automation way to change it programatically. So far we do not experience any echo issue with many popular UC apps(incl. but not limited to Zoom, Webex, SfB etc.) tested in our lab. And Lifesize is new to us, we'd like to give it a try if we could get hold of a free trial version. Currently we're not certain about what role the sample rate plays in the echo issue you're reporting. In a long run we'll consider whether and research how we could support a configuration for switching among sample rates.

Thanks, and feel free to let us know should you have any feedback.

bcoserinf
Contributor
Contributor

Hi,

we face the same issue with Blast and RTAV and it's not new. We don't understand why we can't change the audio sampling rate as we want. We have already reported this problem in this thread in 2016. It's the mean reason why we had stick with pcoip protocol until this year since Blast permit audio at 16KHz and we have problem with pcoip and video in Zoom. 16Khz audio is OK but not match Pcoip yet.

With agent 7.8 we were able to force the audio at 16KHz between each login but the agent 7.12 seems to change the way audio RTAV is handle and now we return back to 8KHz between each session.

Furthermore, the Blast RTAV don't permit 16KHz audio if the video resolution is set too high. We did a lot of testing and the maximum video resolution we can reach with 16Khz audio is 352X288... If we push more than this the audio step back to 8000Khz despite the user select 16Khz in the audio driver.

Blast Extreme works pretty well but the audio quality was a problem since the begining. It's a big drawback in conference application, more than a poor video quality. Again, why just let administrators decide what is best for their use case? We have the choice with video so why not audio?

Thanks!

danielkrause
Enthusiast
Enthusiast

Hi

we are using Webex and Microsoft Teams.

With RTAV we have the same issues.

I am absolutely not happy with the quality of the Sound in VDI, espacially about the packet loss rate. The customers today are used to perfect sound quality and good images quality and cannot understand, that a smartphone can deliver that and a vdi not in the same quality.

Webex and MS Teams / Jabber providing VDI Hybrid programms, that stream from the thinclient the signal to the VDI Session.

So this would be a good solution.

Saidly we have PCoIP Zero Clients, so we cannot use it.

0 Kudos
jroback
Enthusiast
Enthusiast

@ofox

Thanks so much for offering to look into this further!  I can certainly get you set up with a demonstration account on LifeSize to test things out.   I'll send you a direct message here with my contact information.

Thanks again,

Jeff

0 Kudos
serinfbco
Enthusiast
Enthusiast

We've been searching a way to change the mic quality (8khz to 16khz)

I've made a script that forces to 16khz. It writes back the hexdata where it stores the 8khz to 16khz part (by comparing with regshot)

Vmware Blast - Script to change microphone audio quality to 16khz - Workaround

Hope it helps someone, it works for us, the users don't report back about losing mic input or quality.

You should test it before the prod Smiley Happy

jroback
Enthusiast
Enthusiast

Thanks so much for sharing this!   Will give it a try!


Jeff

0 Kudos
jroback
Enthusiast
Enthusiast

One additional thing I've been thinking about is taking the audio inputs and outputs and routing them outside of the RTAV connection by directly selecting either the teradici audio device or a USB headset directly.   I am concerned about getting lip-sync issues between audio and video if we go this route, however.  But haven't had time to try this yet.

0 Kudos
EaBarrus
Contributor
Contributor

Hey @bjohn, sorry to revive an old thread but did you ever find a solution to this issue?

0 Kudos
bjohn
Enthusiast
Enthusiast

Unfortunately, No.

0 Kudos
Franklin2
Contributor
Contributor

I am experiencing the same issue! I have found that manually changing the sample rate from 8000 to 16000 fixes our audio issues. This is something that needs to be fixed! 


Running 7.13 and using vmware blast 

I dont have this issue using PCOIP and teraidici driver but trying to improve webcam quality and  blast is better with that. 

HELP! 

Tags (3)
0 Kudos
ECBCBSMA
Contributor
Contributor

Not revive an old thread, but we were still struggling with this on Horizon 2111.  We actually have a solution, just wanted to pay it back.  While it's true, Microsoft has remove all the common current methodologies for modifying sound from the command line, old methods still work.  Using an older utility, View / change sound volume on Windows from command line or GUI (nirsoft.net) from Nirsoft, you can change the capture device sample rate from the command line.  Combined with the logic from Serinfbco's script (Vmware Blast - Script to change microphone audio q... - VMware Technology Network VMTN), we have been able to create Scheduled Tasks on our VDI non-persistent machines that will enforce 1 channel, 16 bit, 48000 Hz sample rate for all active capture devices.  If anyone is looking for a solution to this old RTAV issue still, this works.  Good luck.

Franklin2
Contributor
Contributor

Thanks!
We still have this issue and need @VMware to come up with a better solution! 

0 Kudos
serinfbco
Enthusiast
Enthusiast

Hey, great find !

Didn't know SoundViewVolume could be used, and it works. It can be run by the user. The script can be placed in GPO users login scripts.

Here my vbs:

 

Const HKEY_LOCAL_MACHINE = &H80000002
strKeyPath = "SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Capture"
Set objShell = WScript.CreateObject ("WScript.shell")
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")

wscript.sleep(10000)

objFSO.CopyFile "\\networkdrive\SoundVolumeView.exe","C:\folder\SoundVolumeView.exe"
'WScript.Echo key
oreg.EnumKey HKEY_LOCAL_MACHINE, strKeyPath, arrSubKeys
If Not IsNull(arrSubKeys) Then
    For Each subkey In arrSubKeys
        'WScript.Echo subkey
        subkeypath = strKeyPath  & "\" & subkey & "\Properties"
        oReg.GetStringValue HKEY_LOCAL_MACHINE, subkeypath, "{b3f8fa53-0004-438e-9003-51a46e139bfc},6", strValue

        
    	'wscript.echo strValue
        if instr(strValue, "VDI") > 0 OR instr(strValue,"Vmware") > 0 then
            If objFSO.GetFileVersion("C:\Program Files\VMware\VMware View\Agent\bin\wsnm.exe") = "8.4.0.0" then
                objShell.Run """C:\folder\SoundVolumeView.exe"" /SetDefaultFormat """& strValue &""" 16 48000 1",0,true
            else
                objShell.Run """C:\folder\SoundVolumeView.exe"" /SetDefaultFormat """& strValue &""" 16 16000 1",0,true
            end if
        end if

    Next
End if

 

0 Kudos