Community

As the title suggests, when there is a hiccup, the picture skips a beat, while the sound lags behind.
Is this an effect of the screen sharing happening over UDP and the sound over TCP?
Not sure if this is initiated by a CPU spike on the remote computer or a WiFi bridge hiccup.
I'm thinking the sound should do the same as the picture and "just" skip a little, it quickly becomes tedious to restart the audio conference.
(Also I'm feeling that the sound gets a bit grainy after it's transmitted, is this an effect of a compression algorithm?)
Any fixes in setting, or is this something for the developers to solve?

Polina wrote:

Hello Laslo,

Thank you for your message.

Could you please let us know which version of Remote Utilities do you use? In case if you use version  6.10.10.0  or an older version, then please try updating your Remote Utilities installation to the latest  6.12 Beta 4  version as the issue might have already been fixed in the latest release.

The latest  6.12 Beta 4  version of Remote Utilities is available for download on this page.
When updating, please make sure to update  both Host and Viewer to the same version  in order to avoid the version mismatch that might lead to performance issues or some features not working.

Please let us know if the issue with the sound persists even after updating or if you already use the latest 6.12 Beta 4 version.

Looking forward to your reply.

I have now tried the latest beta on 2, 2 hour long sessions, and when some type of lag hits, the picture still catches up by skipping frames, but the sound lags behind and I have to restart the call to avoid confusion.

Both machines are Windows 10 x64. One (i7 3770) is running Host and Pro Tools 12, with various plug-ins, and the other (i7 4770) is basically just running the Viewer. (We are doing some Covid-safe studio recording, where I'm in another building engineering vocalists in the studio.) Can't supply you with video, but I can basically tell you exactly what happens_ On the viewer side both the picture and sound freezes for maybe a second, then the picture feed jumps to where it needs to be and the sound lags behind. On the host side, the sound freezes, then comes back and lags behind. I can't confirm exactly what's happening on the host side due to logistics and time constraints. My own suspicions are either heavy usage of CPU on the host (by ProTools), or a hitch in the WiFi bridge. Still didn't get a good answer if the sound is transmitted by UDP or TCP, and why it doesn't catch up like the picture does.