Mumble voice suggestions (and improvements)

@deterministic_bubble sorry for the ping, I am yet new with Discourse quoting.

Curious. Maybe we’re violating a protocol spec somewhere still?

Were you using a Murmur 1.4 branch version?

Nope, I was running stable 1.3.0.
Re-tested it today to remind myself what was wrong and to provide more sofisticated details since I wrote it as extra case and… targets work fine - at least player ones, but game client does not create any channels at all (neither temporary or static), ACL’s adjusted of course.

What else I’ve forgot to post (keyword: violation - thanks for reminding!), when connecting classic Mumble client 1.3.3 to FXServer built-in Mumble, sometimes you get protocol violation error:

xFEHWhIA

It would be cool to protect the built-in server with any authentication, since now anyone can connect with any client and do actually bad things.

That’s curious. Define a ‘voice loss’ here?

What does and doesn’t happen in such a case? Packets are piped through the exact same way, so it’d be confusing for whatever issue with packet handling to happen more frequently with native audio enabled.

Still working on collecting data for this. One of our administrators occured this during night after I’ve asked for data collection, so I’ll post what I got for now:

  • complete randomness, I don’t know yet how to reproduce it, since he was walking for 2 hours talking and then voice just stopped working
  • he made a full dump, since yesterday I didn’t pass information about ETW tracing: https://drive.google.com/drive/folders/1nvdwUSXiiEcNSuFxtLgMXWvb0HEs8cLX?usp=sharing
  • what he discovered, is that his ped model had no face animation even when he talked, so it seems the game client didn’t detect any voice

I’ve asked once again, to test for us is ‘talking’ flag passed and to collect pcaps from client that isn’t heard and from client that isn’t hearing.

What interior, for example? I asked earlier in this topic and didn’t get any feedback on that.

Test case: hei_dlc_heist_police aka police building at Mission Row.

Dumps are not really what one needs for ongoing issues, they’re just as last resort for ‘stuck’ states.

If a ‘spike’ in this case means ‘a stutter/hitch/… of the full game’, or ‘voice stuttering while seeing a CPU use increase’, an ETW trace while such is going on (of the client) would help more. Usual caveats apply: fast sampling, trace to file, not circular buffer, and trace for 20-30 seconds max.

Naming it correctly: around 1 second hitch (complete client freeze).
We shall have ETW traces for this today.

This was an external PR, so it might have inherent issues in its implementation.

Is this reproducible even without any players, say, by repeatedly switching servers? It might be the PR forgot to reset some state somewhere or such.

Not sure, going to test it as the last thing. You can surely reproduce it at our environment.

This is a known issue but mostly tangential to the aforementioned.

Still, shouldn’t it silently abandon reconnection if there’s no game session?

Will come here back within 6 up to 8 hours with more data.

most likely some state are not reset, I had some client crashes when using it (here).

Disabling built in mumble server in components.json resolved the issue.
I could not reproduce without players and switching between both server, seemed to happen way more when many players.

After testing out native audio in a 100 people server we noticed a few things as mentioned above, much reverb in some interiors like the pacific bank, which doesn’t seem to be affected by microphone volume / range switching. Most importantly we noticed that the calculations seem to be very attached with the camera since its native audio but that poses a few issues like:

  • When setting a low value to be used as a whisper mode for example (< 1.0), the other players can hear you really loudly if they place their camera looking right behind your ped.
  • When in a high speed (>250km/h) vehicle, voices stutter if the range is not big enough because the voice seems to cross the camera point too fast. This is a lot more noticeable in first person mode with someone talking in the back seat / trunk positions.
  • When in cinematic camera / idle camera, same behavior can be noticed of not hearing people properly / stuttering in high speeds (>250km/h).
  • When entering a big vehicle where the camera focuses out, same behavior can be noticed.

voice_useSendingRangeOnly seems to have no effect, at least noticeable enough.

On the good side, the echo when its not too much it sounds great and the reaction of voice with the world around its amazing. The recently introduced RadioFX submix filter is also great!

If we could combine how the voice reacts with the camera in voice_use3dAudio while keeping the rest of the good stuff of native audio, it would probably end to the best outcome.

P.S.: Tests were performed with all clients in Canary today and server version 3246 (Windows), using a grid-based system.

That’s our feedback, thanks for the great work Cfx.re!

Managed to get 'em?

Right, about this one - audio input indeed seems to be ‘stuck’, that is: WASAPI is no longer signaling the audio input event.

Did the user have any errors output in F8? Did they maybe unplug/replug their audio device? Any other particulars about their audio setup?

Nope, nothing happened. Sorry for the delay on the more data, I should have it tomorrow, had a break.

Implemented now, I hope.

1 Like

Can confirm it does work :slight_smile:

I think this commit was trying to fix this but it actually made it worst.
The crash was not present with mumble server component disabled but now it is present no matter what:

Mumble is the main source of client crash on our server.
I have been trying to get a repro but was not able to get one :frowning:

and you’re also not even trying to get a (full) dump, good job?

No but I got you a nice paint montage :upside_down_face:
Here I managed to get a full dump:
https://plik.root.gg/file/YClsx4p1PCiuBaEY/jqscAcsH9SsOIwpz/crashMumble.7z

Can anyone give a good conclusion to this topic :sweat_smile:

Its better but:
Still too much reverb in Native Audio in some places.

Also Native Audio cannot be heard outside the game. Not a bug tho, but people like it. For example you are the owner of a shop on a RP server and you have your game minimized it is nice to be notified when someone enter your shop and start talking to you.

Another “not a bug” with Native Audio is that sometime you cannot hear people inside if you are outside even if the door is open. So if you are talking to someone, as soon as he will cross the door frame he will be muted.
But that is only happening on custom MLO (even from good mappers like Gabz or UncleJust)
I would say that 3D with sending range is still the best atm.

Better support for external servers would be nice also. Maybe a convar to avoid disconnecting from built in server to external server.

Which places?

It can if you disable ‘Mute on Focus Loss’ in game audio settings. It’s rather a bug that non-native-audio can be heard.

Then… add correct metadata, or provide some repro so that interiors without metadata can be ignored?

Or you can provide some non-weasel-word information so that things can be fixed?

I’m not even sure which items are still ‘to-do’, everything that can be implemented is implemented and other than that people are forgetting to report back with info on their perceived issues. :confused:

For Example in the Tequilala and interiors in general. Also people talking really close to you sound weird.
Repro coords: -555.33 285.49 82.18

I have found that running SetAudioSpecialEffectMode(0) every frame disable the reverb but it might have side effects. Maybe something to investigate.

For example this pillbox MLO, main entrance at 298.85 -584.64 43.26
https://plik.root.gg/file/6ioGTGHwdIJYccPn/PgRyjU0oeb3bku4w/pillbox-v2.7z

I meant voice_use3dAudio and voice_useSendingRangeOnly is best at the moment.

Also I got you a full dump for the client crashes, let me know if I can do something else, I tried to get a repro but I was not able to get one on a local server.

1 Like

I would personally love a way to control echo/reverb natively better. The way currently is quite complex if one looks at Nikez’ occlusion repository. Another place to add that has insane amounts of it is the Mission Row Main Lobby in stock gta.

It would be great if we can change the volume calculation from the camera position to the ped position.

Just now it turns out that we hear players not from the first person, but from a certain spirit flying around, with all the consequences such as: the ability to eavesdrop from around the corner, “crackling” when the camera rotates quickly, and so on.

Does any game work like this? Also, for native audio this might be way too much effort since game code is not as picky as you folks and legacy 3D audio is meant to be dead so is not going to get random code that complicates it even more and might break it.

Also,

Huh?

Is that with native audio, even?

Also ‘and so on’, lol.

Does any game work like this?

I unfortunately do not know any games where there is a 3d voice at all :sweat_smile:.

Is that with native audio, even?

Yes. We tried all combinations of configurations, but the problem still persists. This is certainly not very distracting, but it feels. This is especially felt when two players are standing close to each other.

Also ‘and so on’, lol.

I’m talking about gameplay features, not bugs. I have not yet checked how else I can turn the camera to get an advantage.

Voice still has a weird effect on Native audio compared to 3D audio.

If you have Native audio enabled and run the following whilst outside in the middle of the street, it is how voices should sound compared to it without, in my opinion: (if it helps)

CreateThread(function()
	while true do
		Wait(0)
		SetAudioSpecialEffectMode(1)				
	end
end)