Yea, not sure why I said that. When testing today I found the reverb balanced/good in all the interiors I tested. 
Other than that, yup that was a submix request. For real tho, beautiful work with native audio recently. 
For now all bugs seems like fixed perfectly.
I can use radio perfectly.
I can use NativeAudio perfectly.
No more audio problem while going too fast.
Hello,
as there was no lazy ass to provide proper dumps for @nta, here we go.
Today we’ve switched with @grzybeek from 2dAudio+sendingRangeOnly to nativeAudio, unfortunately not everything seem to work as expected, so: is this expected?
- Configuration A - 2dAudio+sendingRangeOnly+modified version of grid system (channel targets and player targets for vehicle passengers)
- Works very well.
- Players had random complete voice loss, but it occured rarely, and, we have a simple reconnect command for mumble, as we are running an external server (it runs on pure FXServer as I had no luck with both Grumble and Murmur running voice targets) - unfortunately MumbleSetServerAddress seem to have an issue too, but will try to explain this later in this message.
- Configuration B - nativeAudio+same version of grid system
- I have to admit, its outstanding (yet, that comment was unecessary) as for a built-in voice addon.
- The complete voice loss occurs more frequently, and any reconnection does not work properly.
- Interiors reverb is really too huge, whilst standing in a simple room you have a feeling like you would be visiting a church.
- Game client tend to spike when there are lots of changes in player scope, I’ve explained it a little more over Discord:
Is it expected that joining into much populated scope causes the game to spike until all scope changes finish? Tried to watch resmon a little bit if it could be my scripting issue, but observing neteventlog throws only scope join/drop events.
What is weird - I’ve switched from 2d audio with sending ranges to native audio few hours ago, and one of my developers started to suffer from those spikes since then, whilst he hadn’t that issue before the change.
I got it confirmed too - the spikes on scope changes are much more overloading client for players with around 200 (some scopes can get to around 40-50) online when using native audio implementation over x3da.
Yes, after we got reports on those spikes, I’ve switched from nativeAudio to 3dAudio and the problem disappeared.
-
Full client dump running native audio:
https://drive.google.com/file/d/1bMM09Vfi3zUdue8N7V9JK893H3ISgWga/view -
Full client dump after an hour, after switching to 3d audio:
https://drive.google.com/file/d/11jr2bhukruXEZihpCcCt-2bQqqKLsqp0/view?usp=sharing
I will try to provide as soon as possible a dump during the complete loss.
Last but not least, MumbleSetServerAddress
As mentioned previously, our external server runs pure FXServer with everything disabled, just to handle the voice.
During client join phase everything works fine:
^ while joining the session, you get list of players, channels are created, and so on. COOL.
When I call the native while gaming, this scenario happens:
^ first attempt: OK
So, let’s try again after few seconds:
^ second attempt: Mumble got some trouble, but it connected
Same scenario, waited some time after connection got established:
^ third attempt: Lots of trouble, retrying until success (while catching this screen, my client didn’t manage to connect after 8 retries)
Since then, the client tries to re-establish connection until success - COOL. In the end it manages to connect, but its like random which retry it won’t get broken data.
This certain simulation didn’t give me the most common scenario I’ve occured whilst observing the console while calling the native last month. Typically I just had “connection failed: operation canceled” after/during the client receives list of players, without broken pipe error.
So I’ve tried again just to get the case described above, but no luck - after joining server for the second time and calling the native manually, instantly getting broken pipe error after receiving player list.
Meanwhile, I’ve found another thing - I don’t know is it related to this native, or just Mumble thing: when you get dropped or disconnect from a server, Mumble keeps trying to reconnect, even when you are not connected to any server:
^ this happens when you are successfully connected as well as during reconnection process.
PS
bubble, if you need, we can provide you with @grzybeek address to our external Mumble so you can test it yourself. I guess it might occur only under certain load, and as you cannot simulate most stuff yourself outside own brain, we are up to give you any necessary tools.
3 Likes
Curious. Maybe we’re violating a protocol spec somewhere still?
Were you using a Murmur 1.4 branch version?
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.
What interior, for example? I asked earlier in this topic and didn’t get any feedback on that. 
“spike”?
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.
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.
This is a known issue but mostly tangential to the aforementioned.
@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:
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.
Can confirm it does work 
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 
and you’re also not even trying to get a (full) dump, good job?
No but I got you a nice paint montage 
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 
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.
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.