Scenario: Run Clumsy on the server, we tested with 90% chance drop on inbound/outbound UDP/TCP port 30120 for ~15 seconds. Stop. Do /vsync to move back into the appropriate voice channel (determined by grids) or move out/in of the grid.
Result: VOIP recovered, no intermittent/choppy audio.
Scenario: Run Clumsy on the server, we tested with 90% chance drop on inbound/outbound UDP/TCP port 30120 for ~15 seconds. Stop. Do /vsync to move back into the appropriate voice channel (determined by grids) or move out/in of the grid.
Result: VOIP did not recover, it had intermittent/choppy audio between both clients. As in, client 1 heard client 2 intermittently and vice versa.
Additional information: Disconnecting one of the clients and reconnecting it did not change the behavior at all, however disconnecting both clients and then reconnecting fixed the issue.
I’m not sure what this tries to accomplish - any reconnect I was able to induce has the client end up in the correct channel fine.
Then again, I wasn’t able to cause any actual Mumble disconnect using Clumsy at all, even when dropping for the longest permissible time before the game would go disconnect itself for a timeout.
Nor would I have been able to test the actual issue reported here, since I don’t have multiple clients with audio support; I was just surprised by the mention of having to re-enter a channel on reconnect.
OK, I managed to replicate the case where reconnecting clients don’t end up in the right channel (likely as pma-voice spam-created 1024 channels?) but even with native audio I’m unable to replicate any case of ‘intermittent/choppy audio’: sound was perfectly fine upon resync.
Fixed the channel-reconnection thing, but I’m unable to replicate any sort of ‘choppy/intermittent audio’.
What I’m doing:
Running a server with phpmyadmin-voice enabled on the host machine, and native audio replicated.
Connecting one client to localhost, and another Hyper-V client to the host IP.
Setting the Hyper-V client to loopback (using VB-Audio Cable) a random HTML5 audio demo into game voice.
Using the expression (udp and (udp.DstPort == 30120 or udp.SrcPort == 30120)) or (tcp and (tcp.DstPort == 30120 or tcp.SrcPort == 30120)) in clumsy, dropping packets for ~15 seconds, noting both clients will drop from the Mumble server.
Once reconnected, the clients appear to be able to talk fine. There’s a small buffer anomaly audible as the clients reconnect, but after that, voice data seems to be perfectly normal.
Client now reconnects in the previous channels but if a voice target was set (with MumbleSetVoiceTarget) then all the channel and player targets (MumbleAddVoiceTargetChannel and MumbleAddVoiceTargetPlayer) are gone and the other people cannot hear the client anymore.
Before we could detect that the client was sitting in the root channel and manual resync him.
For us this change is a regression.
Could be good to have an option to not move client back to the previous channel on reconnection
Video on canary:
edit: the client disconnected by turning off voice chat in the gta settings
Ah, right, I suspect these need replaying as they’re tied to the player connection.
This is what you get if you implement a workaround instead of reporting a bug. Prime example of why I tell people to report issues and not make weird custom workarounds!
No, would be extremely bad, there’s no reason to if said issue is fixed as well. Having ‘options’ is generally a bad thing, as it leads to even more configuration sets to check when troubleshooting, especially if this ‘option’ is only needed to make a workaround for an unknown, unreported issue work.
As to the original issue, I’m not sure what is making @nikez able to reproduce this consistently - maybe the fact the server is remote and has some latency has some effect, will check this with him at a later time when I’m not exhausted all day.
Not entirely sure how you can’t get it to repro… We get it to consistently repro without fail when we connect to a remote server with ~150ms, I’ll try on my own box later to see…
We actually managed to get an even easier repro. No need for Clumsy, just toggling “Voice Chat Enabled” off and on again will induce the same behavior as described. Connecting a normal Windows Desktop Mumble client to the same channel (so you can hear people in-game), they will also come through ‘intermittently/choppy’.
Edit: This should mean that I can reproduce this alone by having myself connected as a FiveM Client + a normal Mumble client and just listen to myself speak in-game. Perhaps that can help?
That makes even less sense for it to only happen with native audio for you, then, as that’s in the input logic and not output logic, where input logic is the same no matter the audio output mode.
Also, it didn’t repro for me at all even when doing that, as that’s what I tried before the whole two-client charade with clumsy.
Cool, but opinion isn’t the point here, and the option in reference Murmur is also not related in this case as your use case for it is to signal to scripts to reset voice targets on reconnect.
Why would you need an option to undo a fix as you relied on some unintended behavior, when you can have a script event queued on reconnect instead (which also means you don’t have to poll channel state anymore!).
Also, I’m not sure if that push to the first PR you did got broken now - branches might be a bit non-obvious.
I haven’t tested on my localhost yet as I need to head to bed… I’ll continue testing tomorrow.
Test 1 with 3dAudio
1 Mumble client
1 FiveM client
Result: I heard myself garbled through the mumble client
Test 2 with 3dAudio
1 Mumble client
2 FiveM clients
Result: I heard myself garbled through the mumble client, however, the secondary FiveM client heard my crystal clear (as opposed to when doing the same test with nativeAudio)
So listening to yourself through the Mumble Client doesn’t seem to be a viable test
Server was on my local machine this time.
FiveM Client 1 is localhost
FiveM Client 2 had ~320ms to me (Australia -> Sweden)
Test 1 with nativeAudio
1 Mumble client (Localhost)
2 FiveM clients
Result: I was not garbled while listening to myself in Mumble after toggling VOIP. FiveM client 2 (Australian) heard me just fine before and after toggling VOIP, however FiveM client 1 heard FiveM client 2 garbled in both Mumble + in-game.
Test 2 with 3dAudio
1 Mumble client (Localhost)
2 FiveM clients
Result: I was not garbled while listening to myself in Mumble after toggling VOIP. FiveM client 2 (Australian) heard me just fine before and after toggling VOIP. FiveM client 1 and 2 heard each other just fine before and after toggling VOIP in-game. However, Mumble client heard FiveM client 2 garbled!
EDIT: Clarification: both clients toggled VOIP on and off
Aaaaaand finally I tested with completely locally with cl2: no issues with 3dAudio nor nativeAudio.
Edit: Tested with a remote server (nativeAudio only for now) and two FiveM clients from my own box (cl2), the one client that toggles voip on/off emits garbled voice in-game and to the mumble client, the other client which didn’t toggle VoIP comes through cleanly both in-game and mumble.
Yeah, suspected it to be something with the input portion anyway, curious how XA2 seems to compensate for broken/whatever buffers.
Also odd how this seems to be latency-related mainly, and only starts after a dis/reconnect… even more so since the general use of WASAPI audio capture seems to match what the reference Qt Mumble client does.
Thank you for the connectevent.
One small thing is that when using “MumbleSetServerAddress” it will call Mumble_Connect() even if you have voice chat disabled by script or in settings.
Apparently when reconnecting, UDP output pings seem to fail (wrong crypto state?) leading to audio packets being sent using the TCP tunnel functionality, which apparently has weird flow control treatment.
Sadly, this looks like it might be a server-side issue with the UDP interceptor, which means that this won’t be a magical fix for everyone.
(well, a potential magical fix can be done but won’t 100% work due to UDP source port assignment, heh)
It’s still odd how this doesn’t lead to issues with the XA2 output code, though. Does XAudio2 somehow have special support for randomly-intermittent audio buffer pushing?
… actually I suspect the TCP bits don’t have Nagle’s algorithm disabled. Duh! Why XA2 seems to be impervious to nagling, though, is funny.
The recent changes seem to have fixed the issue for me, thank you very much. I can’t reproduce the issue with toggling nor slamming the server with clumsy.
