WebRTC: Stall when crossing parcel boundaries on Windows

Environment

Second Life Test 7.1.4.8351851435 (64bit)
Release Notes

You are at 138.9, 114.0, 33.8 in webRTC1 located at simhost-07f5f7ddf45b02732.aditi
SLURL: secondlife://Aditi/secondlife/webRTC1/139/114/34
(global coordinates 259,979.0, 245,362.0, 33.8)
WebRTC-Voice 2024-03-15.8291114706
Release Notes

CPU: AMD Ryzen 9 5900HX with Radeon Graphics (3293.81 MHz)
Memory: 15792 MB
OS Version: Microsoft Windows 10 64-bit (Build 19044.3086)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce RTX 3080 Laptop GPU/PCIe/SSE2

Windows Graphics Driver Version: 30.0.15.1278
OpenGL Version: 4.6.0 NVIDIA 512.78

Window size: 1655x848
Font Size Adjustment: 96pt
UI Scaling: 1
Draw distance: 128m
Bandwidth: 3000kbit/s
LOD factor: 1.75
Render quality: 5
Advanced Lighting Model: Enabled
Texture memory: 7273MB
Disk cache: Max size 1638.4 MB (99.9% used)

J2C Decoder Version: KDU v7.10.4
Audio Driver Version: FMOD Studio 2.02.13
Dullahan: 1.14.0.202310131404
CEF: 118.4.1+g3dd6078+chromium-118.0.5993.54
Chromium: 118.0.5993.54
LibVLC Version: 3.0.16
Voice Server Version: Secondlife WebRTC Gateway

Packets Lost: 0/298 (0.0%)
March 20 2024 10:13:27

Description

Crossing between different voice channels (parcel, region, etc.) stalls the viewer for a short time, resulting in jittering framerate.

This happens during the SetLocalDescription webrtc call, which begins doing things like ICE negotiation.
SetLocalDescription may make callbacks into viewer code which in turn are proxied to the main thread, so the obvious thought is that that code is taking too long. However, the code is very small and should complete quickly, and has completed quickly in past measurements.

For the most part, those calls are 'OnIceCandidate' and 'OnIceGatheringState' calls, followed by 'OnAnswerAvailable.' Commenting out those callbacks doesn't fix the problem.

All calls into webrtc are proxied onto the webrtc threads (signaling or worker,) and that is simply putting a call onto the thread queue.

Interesting thing is, this only happens on Windows, not Mac.

I'm wondering if there's some sort of resource contention going on, such as network, which is causing issues.

Reproduction steps

1. set up a parcel with parcel-limited voice.
2. Fly into that parcel from another parcel with parcel or region voice.
3. Observe the stutter in framerate.

or

1. Fly within about 100m of another region.
2. When the viewer connects to that region at that distance, there will be a stutter.

Start at the SetLocalDescription WebRTC call and trace its ICE negotiation, including OnIceCandidate, OnIceGatheringState, and OnAnswerAvailable callbacks and their thread proxies. Reproduce parcel or region crossings on Windows and compare the behavior with macOS; done means the frame-rate stutter no longer occurs during voice-channel changes.