Minecraft Mod issues

[zsawyer]

I have just tested CrossTalk 1.5.0 with Minecraft 1.5.1 and the MumbleLink mod.

Sadly it does not work as intended.

• there is no attenuation (getting quieter as the avatars move away)
• the directional is only an abrupt switching between left ear and right ear (stereo headset) (the other tester [7.1 headset] said it was either only on the right ear or both)
• further testing showed that both ears were working for me when I turned around but when the other tester walked around me in a circle the direction only sometimes worked abit (abit meaning that there was never an audible transition from left to right or similar)
• testing with Mumble running in parallel worked perfectly
• MumblePAHelper reported good parameters (z axis is being zeroed out)

[thorwe]

The attenuation isn't implemented yet, I opted to wait for the first request and here it is.

The tester with the 7.1 headset should test if Teamspeak's native manual 3D positioning works for him:
Outside of game, right click channel -> 3D sound. Teamspeak has regularly problems with detecting those properly, it sounds like it'd be misassigning channels, which would go unnoticed before with mono output.

The hard switching can have two sources, probably both.

First, unlike Mumble, I don't have the liberty to choose how often I send updates due to Teamspeak's server-side antispam mechanism. Per default positions get send rather infrequently - one per second while speaking, every two seconds when silent. Given the rights to do so, there's not only the way to change the spam values as server-setting, but also the possibility to enable servergroups or users to be unaffected by the spam detection. That's rather uncomfortable, but I cannot change TSes mechanism obviously ;)
The update frequencies then can be upped to a more appropriate frequency in the options of the module.
When you turn, your info is updated immediately, that's why it sounds better then as when your friend moves.

Second, I use Teamspeaks "3D Sound API" for the positioning currently. Ofc the algorithm itself may be different to what mumble does. Actually both lackluster, but I haven't had the time for that little project yet. One thing to mention is, neither do handle stereo output any better than just dismissing the depth. Primarily for stereo headsets, there is a way, though. Any so-called "(real) (true) (7.1) headset is in fact a simple stereo headset, difference is it's shown as 7.1 to windows and a so-called HRTF is applied for binaural. Since that algorithm is software, any headset can be "upgraded" to a surround headset. If you feel experimental, a recent comfortable way to do so is offered by Razor and is, surprisingly, called "Surround". I wouldn't opt to listen to music with that algorithm, though, but for Virtual Reality 3D, as games and this module are, that's a fit.

[zsawyer]

Later that night we tested CrossTalk on HL2DM where attenuation was missing as well... appearently by design choice ;)
Please do implement attenuation.

Thanks for explaining the send interval. This makes the setting clearer and we can try fiddling around with that, see if the transition between ears is smoother using that.

We are using our own TS server and can thus fiddle with the flood settings (in fact because we have used ACRE before CT our "Reduced points per tick" is already upped to 75). Also note that ACRE team also updates data frequently so maybe you can get a hint at what optimal settings would be (they also got attenuation working).

The current minimum "Send Intervall" is 0.1 second, taking a frame rate of 60FPS would mean that I need an interval of 1/60 = 0.016 to have the sound update at game speed. I'd like to be able to set that as well (should I submit a separate feature request?).

Also, thanks for the detailed 7.1 problematic explanation, we will check if it can be fixed on his end.

[zsawyer]

CrossTalk/src/positional_audio/mod_positionalaudio.cpp

Line 269 in 36e3a30

*volume = 1.0f; // Who would want low volumes on a voicecom

We - gamers looking for immersion - do! ;)

[thorwe]

It'll be done (when it's done).

[thorwe]

I've put an initial implementation for Volume Attenuation in the beta channel (opt-in in the plugin's general options).
Note that this is completely untested, I'd appreciate getting feedback about the status.

[PvtPirate]

I tested the beta with MumbleLink-mod:
the position update will stay as an issue, but i know you cannot change that.
the attenuation now works, though it is difficult to set up properly if you have no clue about how much 1dB is.
it was bugged in the other version, inverting attenuation: it went more silent when getting closer and had full volume when you walk away past the maximum distance - but apparently you fixed that in the current beta.

for easier setup, maybe you could change how attenuation variables are set by the user:
min distance [m]
volume [%] at min distance [m]
max distance [m]
volume [%] at max distance [m]

past max distance, everything will be at this volume %

[zsawyer]

Thanks for the update and feedback guys. I am sad to not have been able to test it myself so far.

About the sent interval problem: Would it be possible to interpolate the movement and instead of "spamming" the server with updates have the engine calculate an approximate location based on the last few packets of data. This would stop it from sounding like the audio source is zapping around and make it more fluently.

Also the problem that the sent interval value's minimum is 0.1 seconds still persists.

[PvtPirate]

zsawyer, that would not change anything, as the coordinates are being sent in this way
--> CrossTalk --> TeamSpeak
and even if Crosstalk would calculate an estimated next position to be able to send a more fluent strem of coords to TS, this still doesn't allow TS to accept more coordinate updates per minute.
This is the bottleneck and it cannot be changed by thorwe, but only by a serveradmin with corresponding userrights.

[thorwe]

I guess he meant the receiving side would calculate an estimate for the time inbetween incoming info.
I'm not sure about that in regards to bang for the buck (the later being my limited time).

If there are indeed server admins that have a problem with adjusting the flood points, it might be worthy to rather go full and create an optional / second stream via WebSockets, e.g. to a node js server with authentication (maybe meteor) that'd distribute those.

Note that creating an additional ticket for single items is indeed welcome, in general threads I just tend to forget. I'll create one for the minimum update value, however it'll be 0.02s as the mumble link protocol is at a fixed 50 times per second rate for updates.
(#20)

[zsawyer]

True, the interpolation should happen on the receiver side due to the problem described by pvtpirate.
I am still curious how ACRE does it since they do not have this issue (although flood rate is recommended to be turned up for that afaik).

Allowing higher flood rates is a reasonable solution. I understand that spending time to fix something which originates at a different endpoint is not very efficient. I just was afraid (sorry for not checking) that TS's had a floodrate max of 0.1 second so that is why I was not sure if it is even possible to go lower. But you seem quite certain so that will suffice.

[thorwe]

Server Admins can even simply disable the flood detection for a certain user group if they're trusted, so technically there's no hard limit there that ain't exceedable.
It's just a question of the config, sadly my only choice is to set rather high default values to not have users freaking out with default server settings.