Are you using Native Audio?
Since we switched to Native audio we have a lot of reports of loss of voice.
I don’t think it is linked to OVH anti DDOS because everything was fine with 3D audio and also we are using an external murmur server
What the hell does ‘loss of voice’ here mean? @gottfriedleibniz can you take over here as I really have no clue what this topic is turning into…
I meant sometime you will continue to hear people but they will not hear you back or vice versa.
But if the 2 persons start a phone call (volume override) they can hear each other for the duration of the phone call
Example:
client: 2189
Also it seems that GetActivePlayers only returns up to 128 players.
So if you are using this to make a proximity voice system it could lead to some players not adding you to their voice target and vice versa if more than 128 persons are in your scope
nearby only
This thread has quickly become a mess.
manzarek’s “loss of voice” issue should likely be its own thread. overrideVolume working as intended indicates that the client has not been disconnected from the mumble server.
This could have been explained if I was using a “grid resource” and the 2 players where somehow in wrong channels.
But I am only using MumbleAddVoiceTargetPlayerByServerId on all GetActivePlayers that are closer than 100.0 meters and refreshing that every 2seconds.
This 100% started to happen when switching to Native Audio.
I also removed any submix to try but it didn’t help
I didn’t created a dedicated thread because of lack of consistent repro
The game itself can only have 128 players exist at the same time. What the hell are you doing, especially to not also hit other issues related to this?!
If you’re ‘only’ ‘using’ that, that’d mean that players are not in a dedicated channel at all and everyone’s routing to everyone anyway by means of being in the same channel, which would also explain your load issues.
yeah so you choose to clutter a topic with 5 different unrelated subconversations instead?
see what happened to the last topic that turned into a ‘general voice complaint topic’.
Cleaned the topics up instead and split 'em.
I have 0 load issue, I assign a random channel from 1 to 100 to each players
At 833 players:
That should explain invisible players during “big game events”
Edit: I tried grid, I tried proximity, I tried internal, I tried external, all of them had “loss of voice” compared to 3D.
I am sorry if I feel that I am just complaining for nothing but I really want to help to make Native Audio the best audio system out there 
2 Likes
Ok so I was able to replicate a “workaround fix” for loss of voice.
In this video no one called any submix natives, it was completely disabled.
As you can see I can hear one person but not the other.
I then set a submix (0 here, no submix were created manually (no submix natives called)).
I then reset the submix to -1 and I can hear him correctly.
MumbleSetSubmixForServerId(5412, 0)
MumbleSetSubmixForServerId(5412, -1) -- only this is not enough
You can also see in the gamer tags that NetworkIsPlayerTalking was false when I had the voice loss.
There was ~75 GetActivePlayers() if that matters
1 Like
That’s… curious. Does the same happen if you set override volume to something and back to -1.0?
Recreation of audio entity might randomly fix it due to, uh, SetAllocationBucket stuff? Does this only start breaking if you’re in an area with a lot of players?
Yes same behaviour with MumbleSetVolumeOverrideByServerId:
This will fix the voice:
MumbleSetVolumeOverrideByServerId(5731, 1.0)
-- then later:
MumbleSetVolumeOverrideByServerId(5731, -1.0)
But only this will not:
MumbleSetVolumeOverrideByServerId(5731, -1.0)
“Only” I don’t know but it definitely get worse with a lot of players.
And the more players the more you have voice loss.
Almost all players will have at least 1 person they cannot hear during big server events.
1 Like
The issue is still present after this commit.
MumbleSetVolumeOverrideByServerId can be used to fix players
Do you have any better way to replicate this, then? This was tested ~fine with a number of fake clients (multiple instances of a Python client, I believe?) at the time.
Given you’re sending this 5 months later are you sure you’re not referring to a regression or so?
There was no regression in the recent changes, at least not that I know.
The reason I didn’t post for 5 months is that:
- I have not more information on how to reproduce.
- We had two (too?) big events ingame this week that were impacted by this
- More players with the increased slots count by FiveM
- I am currently using the workaround…But that is not ideal/reliable.
It doesn’t seems to be an issue with mumble, mumble server or mumble voice targets.
I don’t know what I can do to make a repro that doesn’t require a lot of players.
I am not sure what a fake client is in your tests, and if that can be compared to a real player ped.
Because if a fake client is equal to a real client in this context that would mean that maybe I am doing something wrong.
But then I don’t explain why only MumbleSetVolumeOverrideByServerId in a runcode would fix a the sound of a player.
Only info I can provide is that is seems to be happening more if you load all the players in the onesync zone a the same time. Example:
You will have a lot of issues if you arrive on a zone with 100+ players
You will have little issues if you are the first player on the zone and 100+ players join the zone one by one. (Which is maybe what was tested with fake clients?)
Code for proximity chat is more or less just:
while true do
MumbleClearVoiceTargetPlayers(Config.MumbleTargetId)
local playerCoords = GetEntityCoords(PlayerPedId())
local player = PlayerId()
for _, nearPlayer in pairs(GetActivePlayers()) do
if nearPlayer ~= player and #(playerCoords - GetEntityCoords(GetPlayerPed(nearPlayer))) < Config.ProximityChatMaxDistance then
MumbleAddVoiceTargetPlayerByServerId(Config.MumbleTargetId, GetPlayerServerId(nearPlayer))
end
end
Citizen.Wait(Config.ProximityRefreshTime)
end
Right, I guess you may instead be hitting some limit of pending commands in some internal audio command buffer then.