Mumble lags and freezing when Left 4 Dead 2 is launched. PA not working

[I-ToRTUGa-I]

Description

So I was trying to use positional audio in Left 4 Dead 2 (2.2.4.1). "Link to game and transmit position", "enable" and "PA" for Source Engine is ticked, but Mumble is getting super laggy and freezing every 2 seconds for me and my friend when the game is launched. Like voice is cracking and even the windows of the program freeze when you move them. Despite this, we checked if the positional audio even works and no, it's not working. We hear each other like in a normal chat (with voice cracking and huge latency ofc huh)

P.S. I am using Mumble for the first time, and there are no specific guides for L4D2.

Steps to reproduce

1. Tick "Link to game and transmit position", "enable" and "PA" for Source Engine
2. Launch Left 4 Dead 2

Mumble version

1.5.634

Mumble component

Client

OS

Windows

Reproducible?

Yes

Additional information

No response

Relevant log output

No response

Screenshots

No response

[davidebeatrici]

For reference, the cause was found in #6491:

On my machine in a debug build, the constructor to ProcessWindows takes about 380ms for Grounded. It's largely from HostWindows::modules() and I think that is mostly time spent in VirtualQueryEx.

To be fair, VirtualQueryEx() is called several times (at least once per module) but it has no business taking so long just to retrieve some info.

And I'm not aware of another way to read the info we need...

I'm not aware how this plugin needs the information from VirtualQueryEx() anyway. It just needs the base address of the executable module. I think that tends to be the first module, but even if it looks modules up by name, the name is part of the MODULEENTRY32 from iterating with Module32First and Module32Next. So, at least for this plugin, it seems like HostWindows::modules() is doing a lot more work than it needs.

Nevertheless, it's probably not a bad idea to run this plugin initialization stuff in another thread instead of the main/GUI thread. But I haven't looked into how much work that would be.

You're absolutely right. We simply never noticed the issue until the new plugin framework became a thing (HostWindows already existed prior to that).

In my opinion plugin initialization should happen in a separate thread in any case, especially because the plugins that may be installed by a user are not guaranteed to be programmed correctly.

As for the modules: only a few games I've encountered hold memory areas of interest in libraries rather than the (main) executable. Refactoring the interface so that it doesn't iterate through all modules by default would make fully sense.

[davidebeatrici]

Upon further investigation, VirtualQueryEx() appears to acquire some kind of lock in the target process, which explains the poor performance. The locking mechanism is probably there to prevent potential race conditions, but in my opinion it's just a bad design overall.

In any case, we'll take care of improving our own code so that the client is not affected by that anymore.

[I-ToRTUGa-I]

I hope you can solve this problem. This app has huge potential. I wish I was a coder to understand all this and help you...
Thank you for answering.

[davidebeatrici]

No worries, this is high priority for us.