webRTC: multi-agent voice calls often fail with 2025.07 on certain USB headsets

[maestrolinden]

Environment

Second Life Viewer 7.2.2.18475198968 (64bit)
Release Notes

You are at 246.4, 147.5, 23.0 in webRTC1 located at simhost-0462d668818ec3f3b.aditi
SLURL: secondlife://Aditi/secondlife/webRTC1/246/148/23
(global coordinates 260086.0, 245396.0, 23.0)
WebRTC-Voice 2025-09-26.18046863877
Release Notes

CPU: Apple M1 Pro (2400 MHz)
Memory: 16384 MB
OS Version: macOS 26.0.1 Darwin 25.0.0 Darwin Kernel Version 25.0.0: Wed Sep 17 21:41:45 PDT 2025; root:xnu-12377.1.9~141/RELEASE_ARM64_T6000 arm64
Graphics Card Vendor: Apple
Graphics Card: Apple M1 Pro

OpenGL Version: 4.1 Metal - 90.5

Window size: 1277x822
Font Size Adjustment: 96pt
UI Scaling: 0.75
Draw distance: 96m
Bandwidth: 10000kbit/s
LOD factor: 1.125
Render quality: 1
Texture memory: 12124MB
Disk cache: Max size 2150.4 MB (9.0% used)
HiDPI display mode:

J2C Decoder Version: KDU v8.4.1
Audio Driver Version: OpenAL, version 1.1 ALSOFT 1.24.2 / OpenAL Community / OpenAL Soft: OpenAL Soft
Dullahan: 1.24.0.202510081737
CEF: 139.0.40+g465474a+chromium-139.0.7258.139
Chromium: 139.0.7258.139
LibVLC Version: 3.0.21
Voice Server Version: Secondlife WebRTC Gateway

Packets Lost: 0/2584 (0.0%)
October 15 2025 10:32:25

voice server version: sha-433dca1

Description

When joining a multiagentchat webRTC voice call with with the latest 2025.07 viewer, voice chat often fails and then breaks for the remainder of the session. I'm not readily seeing this with the 2025.06 release viewer, so I suspect a regression.

Reproduction steps

1. UserA and UserB: login to the same webRTC voice region
2. UserA and UserB: press the 'Speak' button and speak in voice chat. Verify voice is basically working.
3. UserA: In People -> Groups, right click on a group that UserB is also in and select "Voice call" from the context menu
4. UserB: Click to accept UserA's voice call
5. UserA and UserB: press the 'Speak' button and attempt to talk to each other
   • Note if you can hear the other user
   • Note if you can see the other user's voice indicator
6. UserA and UserB: Click the 'hang up' button to exit the group voice call
7. Press the 'Speak' button and attempt to talk to each other

Expected results:
Voice chat between UserA and UserB should function in the initial spatial chat test, during the group voice call, and after returning to spatial voice chat. Voice indicators should always update to show the current loudness for each speaking user.

Actual results:

• Spatial voice chat works as expected in step (2)
• Group voice chat fails in step (5)
  • UserA sees voice indicator updates for themselves, but at a low update rate (every 3 seconds?)
  • UserA cannot hear UserB
  • UserB cannot hear UserA
• After the users end the voice call, UserA does not reconnect to spatial voice properly
  • They don't see a voice dot for their own avatar, and UserB doesn't see a voice dot for their avatar
  • The 'Speak' button can be toggled off and on, but UserB cannot hear them when it is on
  • This condition persists if UserA closes the group chat conversation
  • This condition seems to persist in general until UserA exits their viewer
  • When UserA exits their viewer, the viewer hangs on this step and must be force-quit: INFO #Voice# newview/llvoicewebrtc.cpp(296) LLWebRTCVoiceClient::terminate : Terminating WebRTC

---

This repo is using Opire - what does it mean? 👇

💵 Everyone can add rewards for this issue commenting /reward 100 (replace 100 with the amount).
🕵️‍♂️ If someone starts working on this issue to earn the rewards, they can comment /try to let everyone know!
🙌 And when they open the PR, they can comment /claim #4833 either in the PR description or in a PR's comment.

🪙 Also, everyone can tip any user commenting /tip 20 @maestrolinden (replace 20 with the amount, and @maestrolinden with the user to tip).

📖 If you want to learn more, check out our documentation.

[maestrolinden]

Doing some more paired testing with @roxanneskelly on this issue, it seems to be related to my USB headset device, "MicroSoft LifeChat LX-6000". This headset is as the default input and output audio device at the OS level, and the viewer is set to just use "Default" for inherit that setting.

I confirmed that the issue also reproduces when no other applications (such as a web browser after a Google Meet call) which might have captured audio are running.

This issue also reproduces on agni, which currently has the sha-8d2161a voice server build deployed.

Here's one example log session from aditi. I logged in, confirmed that spatial voice chat worked properly, started a group voice call (which produced the failure mode described above), then attempted to exit the viewer (which failed - I had to force quit it).

viewer_4833_maestro_viewer_log.zip

I found that when I unplug my "MicroSoft LifeChat LX-6000" USB headset and just use the laptop's built-in speakers and microphone before launching the viewer, then this bug does not reproduce. Unplugging the USB headset mid session crashes the viewer.

[maestrolinden]

Using the same machine and viewer, I tried a different "Sabrent"-branded (but quite generic) USB dongle, which is identified on some systems:

Bus 003 Device 009: ID 0d8c:0014 C-Media Electronics, Inc. Audio Adapter (Unitek Y-247A)

When using this USB device for voice audio (same configuration as the other USB headset - set as default input and output at the OS level, then with the viewer set to use "Default", I see 0 issues doing spatial chat, then group chat, then spatial chat once more. It seems as though this bug really is specific to certain devices, such as the "MicroSoft LifeChat LX-6000" that I originally used to report this.

[maestrolinden]

I repeated the test with this bug between these 2 systems:

• My Mac, running Second Life Release 7.2.2.18475198968, with the (non-problematic) Built-in Speaker and Mic devices used for voice
• a Windows 11 machine (currently 23H2, thought it's upgrading now), running Second Life Release 7.2.2.18475198968 with the "MicroSoft LifeChat LX-6000" USB headset for voice

I was unable to reproduce this bug between these 2 systems. The viewers transitioned between nearby voice chat, p2p calls, and group calls a few times without issue. It would seem that this bug is specific to the "MicroSoft LifeChat LX-6000" USB headset on Mac systems.

I didn't learn a whole lot about the headset when it was connected to my Windows test system, except that it only supports the 44.1kHz, 16bit, 2-channel format for both input and output. Checking back on MacOS via the "Audio Midi Setup" utility, the headset also only supports those exact formats on that platform as well.

[minerjr]

I found an issue and will post a PR that may fix this issue. The current version of the WebRTC codebase is registering all callback methods 2 times and is causing issues as well when users unplug USB headsets as it runs through the code twice to initialize the devices. This may cause a race condition in certain commands where a lock is place and a second lock may happen causing a dead lock.