Basically, it hasn’t really been a problem to date, so few have had any reason to prod the weak points. In fact, it’s something there’s negligible information on and little community investigation has occurred. Synchronizing video to audio channels is very hard, and the use cases to date have meant that few have noticed that it’s not something most protocols do very well at all. And, it’s reached a stage where audio synchronization is likely to become the neglected ginger-haired step-child awkwardly present at the family dinner. However, high-end graphical use cases enabled by datacenter GPU technologies from the likes of NVIDIA, Intel, and AMD mean that frame rates of 60 fps are becoming more common, and other use cases are being considered. ![]() ![]() For Webex/Go-to-meeting/Skype, you are usually more concerned that the voice quality stays high, and you can live with a little flakiness in the speaker’s headshot video.Ī decade ago, graphics limitations, hardware, and network bandwidth meant default VDI frame rates were often 12-16 fps (frames per second) rates (now probably up to 24 fps for commodity VDI/apps), and indeed rates of 10-12 fps are often still used at the low end in protocols such as VNC for support shadowing work. Historically, most protocols have separated audio (traditionally voice) from graphics this makes a lot of sense particularly as different QoS (Quality-of-service levels) can be attributed to different channels. If you poke around in the Citrix system requirements you’ll find that Vorbis and SPEEX are available under the hood. In such a situation, the user has more or less to stop using one of the screens.Whilst the various graphical/video codecs are pretty well known, the vast array of audio and speech codecs is less so, but includes SPEEX, OPUS, and Vorbis. The problem can be solved by synchronizing the zoom factors of both screens but, of course, that is a major inconvenience when the user has several screens with very different DPIs (typically, a laptop or tablet with a QHD or UHD screen and a main display with a 1080p one). The mouse position isn't forwarded properly to the server any more in both screens: the user cannot click on any UI element because the server receives a different location that where the user clicked.This results in only part of the application to be displayed on the client with blue background next to it. The "clipping region" that Citrix uses to display the application in seamless mode get desyncronized with the actual position of the window (on the second screen only).This works fine until the user moves one of the application's windows (even partially) to the second screen. They attempt also have different zoom factor for each screen (display settings -> Scale and Layout).Īt connection, the application gets zoomed according to the display factor of the screen is initially starts on. The users typically have a windows 10 system with multiple display. ![]() The users have a number of different version of the receiver but the problem is the same even with the latest one (4.9 at the time I write this, it wa confirmed at least as far back as 4.2). We are providing an application to external users trough Citrix XenApp 6.5. This is a rather old issue but it's starting to get more and more frequent.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |